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1 .0  INTRODUCTION 


As  aircraft  designers  are  developing  a new  generation  of  airborne  vehicles  that  employ 
redundant  electronic  subsystems  as  a basic  part  of  the  aircraft  design,  automated  system  test 
features  must  be  added  to  the  subsystem  electronics  to  enable  determining  the  systems 
► operational  status  or  to  assist  in  the  isolation  of  system  failures  to  effect  manageable  system 

maintenance.  The  flight  controls  development  study  (task  IV  of  the  SST  Technology 
Follow-On,  phase  II)  deals  with  the  mechanization  of  redundant  electronic  subsystems. 
Specifically,  the  study  compares  analog  and  digital  electronic  designs  for  implementing  a 
triple-redundant  flight-critical  system.  The  study  included  assessing  the  failure  modes  and 
effects  of  the  systems  studied  and  investigated  the  preflight  test  requirements  of  those 
systems  relative  to  a disoatch  critical  system  operation.  The  application  model  is  based  on 
the  stability  augmentation  systems  under  development  for  the  U.S.  supersonic  transport  at 
the  time  of  the  SST  program  cancellation  in  1971 . 

The  flight  controls  development  (FCD)  task  statement  of  work  was  not  directed 
toward  developing  a flight  control  system  for  a given  vehicle,  but  was  drafted  to  permit 
technology  investigations  into  selected  areas  of  triple-channel,  fail-operational,  analog  and 
digital  system  designs.  Interface  requirements,  operational  performance,  failure  protection 
mechanizations,  and  preflight  test  requirements  were  fundamental  areas  to  be  investigated. 
Hardware  /soft  ware  relationships  with  respect  to  a digital  systems  failure  analysis  were  a 
special  item  of  interest.  Laboratory  testing  of  baseline  analog  and  candidate  digital  systems 
was  a part  of  the  FCD  statement  of  work.  The  hardened  stability  augmentation  system 
(HSAS)  of  the  prototype  U.S.  SST  was  selected  as  the  baseline  function  (application  model) 
for  the  FCD  task  studies. 

The  general  background  and  scope  of  the  FCD  task  are  presented  in  FAA-SS-73-2-1 
(ref.  1),  along  with  detailed  descriptions  of  the  one  analog  and  two  digital  systems  studied. 
The  two  digital  systems  evaluated  were  a variable  incremental  control  processor  subsystem 
(ICPS)  (developed  during  the  early  stages  of  the  SST  program)  and  a whole-word  computer 
subsystem  (WWCS),  a general-purpose  digital  processor  design  similar  to  those  currently 
under  development  by  many  flight-control  system  electronics  suppliers.  Specific  areas 
identified  for  examination  during  the  FCD  task  were: 

• General  control  function  operational  performance 

• Sensor  signal  selection  and  failure  detection  processing 

• Redundancy  management  for  fail-operational/fail-passive  system  response 

• System  preflight  test  requirements  and  methods,  supported  by  failure  modes  and 
effects  analysis 

- Analysis  and  laboratory  test  results  on  the  first  three  areas  are  covered  in 

FAA-SS-73-2-2  (ref.  2).  This  report  presents  the  results  of  the  failure  modes  and  effects  and 
preflight  test  studies. 


Section  2.0  of  this  document  highlights  the  background  of  the  SST  program,  which  led 
to  the  preflight  test  area  of  interest,  with  the  scope  and  approach  of  the  studies  conducted 
presented  in  section  3.0.  Section  4.0  summarizes  the  one  analog  and  two  digital  subsystems 
failure  modes  and  effect  criticality  analyses  and  preflight  test  requirements.  Section  S.O 
covers  the  application  model,  HSAS,  preflight  test  mchanization.  Sections  4.0  and  5.0  also 
provide  an  overview  of  the  studies  conducted,  with  the  bulk  of  the  detail  analyses  placed  in 
the  appendixes. 


2.0  BACKGROUND 


■ 


. 


To  achieve  the  most  economically  attractive  commercial  supersonic  transport,  the  U.S. 
SST  designers  incorporated  stability  augmentation  systems  as  part  of  the  airplane 
safety-of-flight  primary  design.  Such  a design  approach  allowed  performance  parameters 
(i.e.,  weight,  range,  cruise  efficiency,  and  takeoff/landing  speeds)  to  be  improved  over  that 
achievable  with  conventional  designs  not  using  full-time  stability  augmentation. 

New  approaches  to  safety  assurance  were  necessary  in  the  design  of  stability 
augmentation  systems  directly  related  to  vehicle  flight  safety.  The  two  most  dominant 
configuration  features  that  were  to  provide  safety  assurance  were: 

• System  redundancy  (multiple-failure  fail-operational  capability) 

• Preflight  system  test  (an  integrity  check  of  the  flight-critical  subsystems) 

These  were  the  primary  study  subjects  of  the  FCD  task. 

Introductions  to  the  Boeing  SST  flight-critical  analog  and  digital  subsystems  are  given 
below.  This  is  followed  by  a section  that  briefly  discusses  system  design/development  areas, 
which  potentially  can  be  more  effectively  treated  with  a digital  system  design.  A discussion 
of  the  SST  system  test  design  approach  and  the  problems  encountered  with  that  approach 
follows. 


2.1  SST  FLIGHT-CRITICAL  CONTROL  SYSTEM 

Three  subsystems  became  involved  in  the  development  of  a flight-critical  control 
system  for  the  Boeing  SST:  an  electric  command  and  stability  system  (ECSS);  a hardened 
stability  augmentation  system  (HSAS);  and  an  automatic  flight  control  system  (AFCS).  The 
ECSS  was  being  designed  to  provide  normal  (desired)  airplane  handling  qualities  throughout 
the  entire  flight  regime.  The  HSAS  was  to  be  an  extremely  reliable  design  providing 
minimum-safe  airplane  handling  characteristics  during  subsonic  flight,  as  a backup  to  the 
ECSS.  The  AFCS  was  to  provide  autopilot  functions  and,  more  significantly,  to  provide  the 
supervisory  control  for  conducting  an  automated  preflight  test  of  the  HSAS  and  ECSS 
systems. 

Both  the  HSAS  and  ECSS  were  four-channel,  fail-operational-squared  (operational 
after  two  failures)  analog  hardware  designs.  Four  channels  were  required  to  achieve  the 
functional  reliability  numbers  specified  for  the  SST’s  2.7-hr  nominal  mission.  Analog 
technology  was  selected  for  the  HSAS  and  ECSS  hardware  primarily  because  sufficient 
insight  into  state-of-the-art  digital  hardware  failure  modes  and  effects,  and  sufficient 
piece-part  reliability  data  on  airborne  digital  computers  did  not  exist.  The  design  emphasis 
for  the  HSAS  was  placed  on  obtaining  the  greatest  component  reliability  with  regard  to 
sensor  selection,  circuit  design,  mechanical  layout,  and  manufacturing  techniques.  The 
reliability  of  the  ECSS  design,  though  stressed,  would  have  been  lower  than  that  of  the 
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HSAS,  since  the  fcCSS  computational  functions  were  more  complex  and  had  more  interfaces 
with  other  airplane  subsystems.  Automated  system  test  and  development  of  simple 
maintenance  procedures  also  received  high  priority  in  the  HSAS  and  ECSS  designs. 


The  AFCS  was  a triple-channel,  fail-operational,  whole-word  digital  design.  The 
three-channel  configuration  was  selected  to  meet  automatic  landing  category  III  « 

low-weather-minimums  safety  criteria.  The  digital  design  became  necessary  in  order  to 
effectively  implement  a preflight  system  test,  determined  essential  to  ensure  mission 
reliability  goals  of  the  flight-critical  control  system. 

The  preflight  test  function  became  essential  because  in-flight  monitoring  could  not 
detect  all  critical  system  failures  while  the  airplane  was  on  the  ground,  and  because 
reliability  requirements  were  based  on  beginning  each  flight  with  no  critical  failures  (i.e.,  the 
integrity  of  the  system  functions,  especially  the  in-flight  monitors,  had  to  be  ensured  prior 
to  dispatch). 

All  three  subsystems  had  essentially  been  designed  and  fabrication  of  the  hardware  was 
well  under  way  at  the  time  of  the  SST  program  cancellation.  Boeing  had  initiated  analytical 
and  limited  laboratory  evaluations  of  these  designs  in  preparation  for  system  validation  once 
all  hardware  was  received  from  the  electronics  supplier.  For  a more  detailed  description  of 
the  SST  flight-critical  control  system  design,  design  requirements,  and  associated  disciplines 
involved  in  developing  such  a system,  refer  to  FAA-SS-73-1  (ref.  3). 

I * 

2.2  DIGITAL  SYSTEM  APPLICATION 

Experience  during  the  SST  program  on  the  development  phase  of  the  HSAS,  ECSS, 
and  AFCS  equipment  brought  out  the  design  inflexibility  of  analog  hardware  once 
fabrication  had  begun  and  the  attendant  high  cost  for  modifying  high-quality  (highly 
reliable,  low-tolerance)  analog  circuits.  This  situation  was  magnified  by  channel  redundancy 
requiring  changes  to  each  of  four  channels  every  time  a change  was  implemented,  and  by 
system  design  sensitivity  (changes  required)  for  each  iterative  refinement  of  the 
airframe /subsystems  definition  as  the  final  airplane  configuration  was  being  evolved. 

Early  configuration  development  of  the  stability  augmentation  systems  for  the  SST 
included  consideration  of  the  use  of  digital  computers.  Trade  studies  were  conducted  on 
all-digital,  all-analog,  and  hybrid  systems.  The  final  configuration  (analog  hardware  for  the 
augmentation  functions  and  a digital  subsystem  for  the  AFCS,  capable  of  administering 
preflight  checkout  of  the  analog  equipment)  was  selected  because  of  the  very  low 
confidence  level  (high  risk)  in  the  applicability  of  digital  computers  for  flight-critical 
functions.  The  state  of  the  art  of  digital  equipment  at  that  time  (1968)  raised  unanswerable 
questions  on  cost,  functional  reliability,  and  development  schedule  risks.  The  selected  SST 
flight-control  electronics  configuration  did,  however,  initiate  the  development  of  a digital 
computer  redundant  system,  AFCS,  but  in  a role  that  could  not  directly  jeopardize  the 
development  and  flightworthiness  testing  of  a prototype  SST  airplane. 

In  the  past  few  years,  digital  control-system  technology  has  advanced  at  an  extremely 
high  rate.  Component  procurement  schedules  and  fabrication  cost  factors  are  more  visible 
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and  competitive  with  analog  hardware.  As  more  systems  are  involved  with  an  airframe 
development  program,  the  digital  approach  offers  a potential  cost  saving  because  of  the 
flexibility  of  its  software  downstream  of  the  hardware  design  freeze  point. 

With  the  termination  of  the  SST  program  AFCS  development,  meaningful  application 
data  on  multiple-channel  digital  control  systems  to  the  particular  problem  of  flight-critical 
controls  are  lacking.  The  intent  of  the  FCD  task  for  the  SST  Technology  Follow-On 
Program  was  to  obtain  such  data  and  determine  the  practicability  of  the  use  of  digital 
control  system  electronics  in  a flight-critical  control  system  application. 


2.3  SYSTEM  TEST  DESIGN  BACKGROUND 

At  the  outset  of  the  Boeing  prototype  SST  development,  stringent  dispatch  and  block 
reliability  requirements  and  flight  safety  goals  were  established  for  the  flight  control  systems 
to  ensure  that  the  systems  availability  and  safety  capabilities  would  satisfy  the  inservice 
needs  of  a production  SST.  It  was  recognized  early  in  the  concept  definition  phase  that  the 
systems  complexity  and  the  time  constraints  imposed  by  commercial  service  operation 
would  require  that  testing  of  the  flight  control  system  be  automated  to  the  greatest  practical 
extent.  Hundreds  of  individual  tests  are  required  to  determine  the  operational  health  of  a 
quadruplex  system.  These  tests  could  not  be  performed  manually  in  the  time  allotted  for 
in-transit  and  turn-around  unscheduled  maintenance  and  preflight  operational  readiness 
testing.  The  digital  automatic  flight  controls  subsystem,  therefore,  was  assigned  the  task  of 
performing  automated  system  test  of  all  critical  elements  of  the  flight  control  system. 

The  term  system  test  was  used  to  collectively  identify  all  operational  tests  conducted 
to  determine  that  the  flight  control  system  was  properly  assembled  and  adjusted,  was 
performing  within  specification  limits,  and  had  not  suffered  failures  that  would  affect  the 
functional  capabilities  of  critical  elements  of  the  system.  System  test  for  the  SST  included  a 
preflight  system  readiness  test,  an  in-flight  autoland  test,  a postflight  maintenance  test,  and 
a periodic  functional  test.  The  latter  test  was  to  be  used  to  perform  required  functional  tests 
following  initial  system  assembb  and  installation.  These  tests  were  also  augmented  by  an 
automated  acceptance  test  (bench  test)  conducted  at  the  line  replaceable  unit  (LRU)  and 
flight-control  electronics  subsystem  level. 

The  automated  system  test  capability  described  above  did  not  explicitly  perform  tests 
on  essential  support  systems  such  as  the  hydraulic  and  electrical  power  generation  and 
distribution  systems  or  the  environmental  control  systems.  These  support  systems  were  to 
be  self-sufficient  with  respect  to  system  test  capabilities.  The  automated  flight  control 
system  would,  however,  determine  the  presence  or  absence  of  the  outputs  of  these  essential 
support  systems. 

2.3.1  Design  Considerations  for  System  Test 

In  order  to  meet  overall  mission  reliabilities,  the  electronic  design  concept  had  a strict 
reliability  budget  both  for  performance  and  departure  delay.  Systemwise,  the  criteria  was 
established  as: 


• A failure(s)  with  probability  greater  than  1 in  10^  flight-hours  shall  not  cause  a 
flight  deviation  or  discomfort  to  passengers  or  crew. 

• A failure(s)  with  probability  between  1 in  10^  and  1 in  10^  flight-hours  may 
require  flight  deviation  but  no  significant  increase  in  passenger  discomfort. 

• A failure(s)  with  probability  between  1 in  10^  and  1 in  10^  flight-hours  may 
cause  marginal  passenger  discomfort. 

• A failure(s)  that  is  catastrophic  shall  not  occur  with  a probability  greater  than  1 in 
1C)9  flight-hours. 

The  reliability  budget  to  meet  these  objectives  was  then  partitioned  into  the  electronic 
subelements  of  600  hr  mean  time  between  failure  (MTBF)  for  the  automatic  flight  controls, 
675  hr  MTBF  for  the  electric  command  and  stability  system,  and  1 100  hr  MTBF  for  the 
hardened  stability  augmentation  system.  Dispatch  reliability,  which  was  defined  in  terms  of 
a delay  because  of  equipment  failure,  was  likewise  strict.  Budget  allocations  for  delays  of  1 5 
min  or  more  were  8.5  per  106  departures  for  all  of  the  dispatch  required  electronics.  Added 
to  these  criteria  was  an  additional  one  related  to  test  circuitry.  Test  circuitry  in  itself  was 
not  to  reduce  the  flight-control  systems  operational  reliability  by  more  than  2%  or 
contribute  to  the  propagation  of  failures  between  channels. 

Given  that  departure  delays  because  of  an  equipment  failure  or  malfunction  was  not  to 
exceed  15  min  or  more,  and  assuming  that  corrective  maintenance  would  not  begin  until  5 
min  after  arrival  at  the  destination  gate,  the  total  times  allocated  for  servicing  and 
unscheduled  maintenance  were  40  min  for  transit  service  and  1 00  min  for  turnaround.  This 
was  based  on  a normal  30-min  through  stop  and  a normal  90-min  turnaround  stop.  The 
assumed  ratio  of  through  stops  to  turnaround  stops  was  1 :9.  The  maximum  times  required 
to  perform  the  automated  preflight  readiness  and  maintenance  tests  were  established  as  5 
min  and  20  min,  respectively.  From  these  test  time  goals,  it  was  evident  that  automation  of 
the  tests  was  mandatory. 

It  was  also  evident  from  the  time  available  for  unscheduled  maintenance  that  a high 
probability  of  isolating  the  failure  to  the  affected  LRU  was  also  required.  This  requirement 
established  the  criterion  that  failures  should  be  isolated  to  the  LRU  with  a 97%  confidence 
level.  It  was  also  required  that  an  in-flight  failure  diagnostic  and  annunciation  capability  be 
provided  so  that  the  flight  crew  could  alert  the  maintenance  crew  in  advance  of  arrival  as  to 
the  LRU(s)  requiring  replacement  during  the  unscheduled  maintenance.  Replacement  LRU’s 
could  then  be  made  available  within  the  first  5 min  of  the  service  stop. 

The  system  test  (preflight  test)  provision  was  to  have  the  capability  of  determining  the 
operational  status  of  all  critical  elements  of  the  flight  control  system.  To  accomplish  this 
with  a 1 00%  confidence  level  within  the  limited  time  specified  above  became  an  exceedingly 
difficult  task,  especially  when  many  elements  of  the  system  were  not  amenable  to 
fully-automated  system  test  methods.  Crew  participation  was  required  in  some  instances  to 
perform  required  functions  such  as  making  manual  control  inputs,  operating  switches, 
observing  displays,  engine  startup,  and  sequencing  the  reference  power  supply  systems. 


Restrictions  on  the  operation  of  engines  (for  prevention  of  noise,  personnel  hazards,  fire, 
excessive  fuel  consumption,  etc.)  further  complicated  the  ability  to  perform  system  test 
under  in-flight  system  interface  conditions. 

Automated  and  semiautomated  tests  were  to  be  employed  whenever  possible  with  the 
AFCS  administering  the  test  sequence.  Flight  and  maintenance  crew  participation  in  the  test 
sequence,  which  was  to  be  kept  at  a minimum,  was  to  be  indicated  by  an  alphanumeric 
readout  of  the  required  test  involvement.  System  failures  and  appropriate  diagnostic 
information  were  to  be  supplied  through  an  alphanumeric  display  and  a subsystem  failure 
recording  numeric  displays.  Control  of  the  test  was  to  be  provided  on  the  same  panel  which 
was  to  annunciate  the  test  in  progress.  Figure  2-1  illustrates  the  system  test  control  and 
display  panel  under  development  at  the  time  of  the  SST  program  termination. 

The  tests  were  divided  relative  to  preflight  and  functional  tests  and  as  to  the  system 
elements  being  tested.  Since  the  AFCS  digital  computers  were  to  administrate  the  tests  and 
judge  test  results,  the  computers  were  to  receive  a full-operational  assurance  test  prior  to 
any  test  on  other  elements  within  the  flight  control  systems.  The  test  programs  were 
segregated  from  the  flight  control  programs  within  the  computer  memory  to  minimize  the 
possibility  of  programming  errors  being  introduced  into  the  flight  programs  when  changes 
were  made  to  a system  test  program. 

Control  of  the  test  process  by  the  AFCS  was  via  a digital  data  link  to  digital  interface 
electronics  contained  within  each  of  the  electronic  LRU’s  being  tested.  The  tests  were 
organized  to  allow  nearly  simultaneous  testing  of  all  electronic  LRU’s.  The  tests  were  also 
selected  so  that  mechanical  and  hydraulic  system  elements  would  be  tested  during  the  tei  s 
of  related  drive  electronics.  The  system  was  divided  into  functional  levels  and  subdivisions 
that  were  directed  toward  achieving  the  97%  LRU  failure  isolation  criterion.  A fixed  test 
stimulus  was  to  be  applied  to  the  circuit  (function)  being  tested,  and  the  response  was  to  be 
measured  against  a desired  response  at  an  appropriate  time  interval(s).  The  design  included 
circuitry  to  isolate  elements  of  the  system  in  order  that  given  tests  effectively  check  the 
integrity  of  specific  functions.  Because  of  this,  end-to-end  tests  were  to  be  performed 
following  subdivision  tests  to  ensure  that  the  test  segregating  logic  had  restored  the  circuits 
to  their  intended  configuration. 

The  preflight,  postflight,  and  functional  system  test  circuitry  was  to  be  isolated  during 
flight  to  prevent  the  possibility  of  in-flight  failures  being  introduced  by  the  test  electronics. 
The  preferred  method  was  to  use  two  independent  switches  to  remove  electrical  power  from 
all  test  electronics  during  flighL  The  minimum  acceptable  approach  was  to  provide  one 
manual  switch  and  one  switch  operated  by  the  ground-to-air  interlock  switch  (squat  switch) 
system  with  provisions  that  system  monitoring  would  verify  that  isolation  had  occurred. 

The  final  evaluation  of  the  system  test  capability  was  to  have  been  accomplished  by 
analysis  and  test  using  success  path  and  fault  tree  analysis  techniques.  The  purpose  of  these 
analyses  was  to  analytically  demonstrate  that  block  reliability  and  system  safety  numerical 
goals  could  be  satisfied  by  the  specified  preflight  and  periodic  tests. 
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2.3.2  SST  System  Test  Approach  Assessment 


Just  prior  to  the  SST  program  termination,  the  system  test  design/implementation 
definition  work  had  progressed  to  a stage  where  several  problems  were  becoming  visible  with 
the  system  test  approach  introduced  above.  Memory,  interface  wiring,  and  digital  interface 
circuit  requirements  had  all  grown  beyond  desirable/acceptable  boundaries  with  serious 
questions  arising  as  to  the  completeness  of  the  tests  relative  to  ensuring  system  pre flight 
integrity.  It  appeared  that  the  approach  taken  was  becoming  a piece-part  system  check, 
which  did  not  take  advantage  of  the  system  redundancy  monitoring  that  existed  in  the 
system.  Each  test  had  been  defined  to  check  specific  elements  such  that  failure  of  the  test 
would  immediately  identify  the  faulty  LRU. 

The  program  terminated  before  a new  approach  (based  on  using  system  redundancy 
intelligence  in  conjunction  with  end-to-end  testing)  could  be  developed  and  before  relative 
trades  between  analog  and  digital  system  mechanizations  could  again  be  reviewed.  The 
following  discussion  relates  specifics  of  the  problems  mentioned  above. 

Memory  Requirements 

The  estimate  of  memory  requirements  escalated  by  a factor  greater  than  three  between 
initial  hardware  definition  of  4,000  words  of  memory  and  program  termination.  The 
memory  requirements  were  still  only  an  estimate  at  termination.  It  was  becoming  apparent 
that  the  AFCS  computer  resident  memory  of  16K  would  have  to  be  expanded.  This  could 
have  been  in  the  form  of  an  additional  memory  LRU  if  all  test  programs  were  to  be  resident 
in  core,  or  alternatively,  a cassette  tape  where  portions  of  the  test  program  would  be  read  in 
and  executed  :.n  block  form. 

Interface  Wiring 

Because  of  the  systems  test  signal  interface  requirements  between  the  AFCS  computer 
unit  and  HSAS/ECSS  LRU’s,  a fourth  computer  interface  unit  had  to  be  added  to  the 
system.  But  even  with  the  additional  LRU,  all  interface  units  required  two  rack  and  panel 
connectors  having  336  pins  each.  Commercial  experience  to  date  indicate  that  field 
problems  can  be  expected  with  units  having  such  a high  pin  count. 

Digital  Interface  Electronics 

The  quantity  of  interface  electronics  required  within  the  ECSS,  HSAS,  and  the 
pitch-trim  control  electronics  to  perform  the  system  test  had  grown  to  the  point  that  overall 
system  reliability,  LRU  volume,  and  LRU  weight  were  adversely  affected.  The  systems  test 
interface  electronics  had  grown  to  approach  50%  of  the  electronics  associated  with  the 
system’s  operational  design-a  level  that  would  significantly  affect  the  HSAS  and  ECSS 
mean  time  between  failure. 

Completeness  of  Test 

Even  with  the  complexity  of  the  subelement  testing  being  implemented,  many 
elements  of  the  remaining  system  had  test  shortcomings  that  would  have  needed  correction. 
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In  some  instances,  particularly  in  the  test  of  the  in-flight  monitors,  the  continuity  of 
interface  wiring  between  redundant  channels  was  not  adequately  verified.  The  monitor 
circuitry  in  each  channel  should  have  been  isolated  and  tested  to  ensure  that  continuity 
existed  from  the  error  signal  source  in  one  channel  to  the  monitor  circuit  in  another 
channel.  Something  that  would  require  a systems  approach  for  testing  system  integrity 
rather  than  a subelement/subcomponent  verification  test. 


3.0  SYSTEM  TEST  STUDIES 


The  FCD  task  system  test  studies  concentrated  primarily  on  determining  the  preflight 
test  requirements  for  the  one  analog  and  two  digital  systems  evaluated.  The  study  objectives 
were  to  develop  an  understanding  of  test  concepts  and  test  procedures,  and  to  acquire  data 
relative  to  subsystem  tests,  test  time,  and  memory  requirements  (presuming  a general 
purpose  computer  as  the  test  administrator). 

Preflight  test  is  the  portion  of  a system’s  automated  system  test  function,  which 
specifically  deals  with  determining  the  flight-critical  control-systems  operational  integrity 
prior  to  takeoff.  The  basic  intent  of  a preflight  test  is  to  establish  for  the  flight  crew  a 
go/no-go  status  of  the  flight  control  system. 


3.1  SCOPE 

The  preflight  test  studies  involved  conducting  failure  modes  and  effect  criticality 
analysis  (FMECA)  determining  test  steps  that  would  check  all  system  critical  elements  and 
developing  test  sequences  that  would  minimize  the  overall  test  time  and  interface  circuitry 
requirements.  A system  end-to-end  test  concept  was  adopted  in  that,  where  possible,  tests 
would  be  defined  utilizing  system  sensor  outputs  to  drive  the  system  with  success 
determined  by  the  servosystem  response.  Where  this  was  not  possible,  test  sequencing  would 
be  based  on  a building  block  approach  where  functions  already  tested  would  be  used  in 
determining  the  test  success  of  functions  yet  to  be  tested. 

Since  the  analog  and  incremental  digital  systems  did  not  inherently  have  the  capability 
to  be  programmed  to  administrate  the  system  test  functions,  preflight  test  for  these  systems 
was  to  be  defined  but  not  operated  as  an  integrated  test  in  the  laboratory.  Laboratory 
testing  of  the  whole-word  system,  however,  was  to  include  an  operational  preflight  test 
function,  coresident  in  memory  with  the  flight  control  laws  of  the  application  model. 

The  SST  HSAS  function  (ref.  1)  was  selected  as  the  application  model  for  the  preflight 
test  studies.  This  model  included  simulated  sensors,  flight-critical  control-system 
computational  electronics,  and  hydromechanical  electric  command  servo-subsystem.  Other 
ground  rules  adopted  for  the  study  were: 

• Flight-control  system  hardware  downstream  of  the  electric  command 
servoelements  (power  control  units  and  interfacing  linkage)  would  not  be 
considered. 

• The  system  was  a triplex  system  satisfying  fail-operational  requirements. 

• All  elements  of  the  triplex  system  were  assumed  essential  for  aircraft  dispatch. 
Dual-  or  single-channel  operational  status  would  not  be  established. 

• Preflight  test  would  assure  that  the  system  is  fail-operational  and  that  all  first  and 
second  failure  detection/ warning  functions  are  operational. 


• Crew  participation  in  the  preflight  test  administration  should  be  held  at  a 
minimum. 


3.2  APPROACH 

The  development  of  an  adequate  preflight  test  is  intimately  involved  with  the  actual 
design  of  the  subsystem  on  which  the  test  is  to  be  administered.  Each  of  the  functional 
blocks  of  figure  3-1  must  be  analyzed  in  depth  to  determine  the  tests  required  which 
establish  that  the  function  performs  properly  under  normal  and  related  failure  state 
conditions.  Test  procedures/sequences  are  arrived  at  by  developing  a functional  flow 
diagram  of  the  system  elements  at  the  hardware  mechanization  level  and  evaluating  the 
design  through  the  FMECA.  The  FMECA  is  used  to  uncover  possible  failure  modes  that  are 
not  manifested  in  a timely  manner  by  the  system  monitoring  functions  (latent  failure 
states).  If  latent  failure  states  are  not  discovered,  a test  is  defined  that  provides  an  integrity 
check  of  the  function  and  associated  monitors.  If  latent  failure  states  are  found  to  exist,  and 
if  they  compromise  the  predicted  operation  of  the  function  following  detectable  failure 
conditions,  two  options  are  available.  The  system  design  can  be  changed  to  remove  the 
possibility  of  incurring  the  latent  failure,  or  a special  test  can  be  defined  as  part  of  the 
preflight  test  function  to  establish  that  the  failure  condition  does  not  exist  prior  to 
dispatching  the  system.  This  latter  approach  must  be  supported  with  a failure  probability 
analysis  which  forecast  the  probability  of  incurring  the  latent  failure  and  subsequent 
hazardous  failure  conditions  to  be  less  than  1 in  109  flight-hours  between  the  running  of  the 
preflight  test  and  completion  of  the  subsequent  flight  (see  sec.  2.3.1). 

This  study  treats  the  application  model  functions  of  figure  3-1 , which  are  within  the 
dashed  enclosure,  i.e.,  sensors,  control  function  processing  electronics,  and  electric 
command  servo-subsystem.  The  control-function  processing  electronics  are  evaluated  for 
analog,  incremental  digital,  and  whole-word  (general  purpose)  digital  designs. 

Failure  mode  and  effect  analyses  of  the  analog  and  digital  systems  present  two  very 
different  analysis  problems.  In  the  analog  mechanization,  dedicated  piece  parts  performed 
specific  functions  for  all  time.  This  permits  the  functional  flow  diagram  to  be  a very  strict 
representation  of  partitioned  circuit  groups.  As  a result,  failure  mode  effect  analysis  and 
testing  becomes  fundamentally  systematic;  i.e.,  system  operation  for  given  functional 
failures  can  be  determined  by  failing  circuit  components,  through  analysis  and/or  testing, 
and  observing  the  system  response.  In  addition,  this  circuit-related  functional  flow  diagram 
allows  tests  to  be  defined  that  check  the  hardware  integrity  as  well  as  the  system  function. 
However,  if  the  functional  operation  is  modified;  i.e.,  hardware  design  changes  made,  this 
systematic  failure  analysis/test  definition  procedure  must  be  repeated  for  the  affected  areas 
of  the  functional  flow  diagram. 

Digital  systems  do  not  in  general  lend  themselves  to  the  same  systematic  failure 
analysis  approach  described  above.  First,  most  of  the  functional  signal  flow  is  facilitated 
through  multiplexing  the  same  component  and  constructing  functions  timewise  by  altering 
the  interaction  or  sequential  operation  of  the  piece-part  elements.  Secondly,  the  timing  and 
control  logic,  which  paces  the  multiplexing  process  of  the  hardware,  adds  an  additional 
dimension  to  the  failure  modes  and  effects  analysis.  Software,  the  computer  resident 


ECTRICAL  POWER 


FIGURE  3-1  - FLIGHT  CONTROL  SYSTEM  MAJOR  FUNCTIONAL  BLOCKS 


program,  provides  the  information  from  which  the  piece-part  components  interact  for  each 
discrete  time  pulse  generated  by  the  computer  timing  and  control  logic.  A system  functional 
flow  diagram  for  a digital  system,  therefore  does  not  represent  the  partitioning  of  dedicated 
circuit  groups.  It  more  closely  represents  the  functions  defined  by  software;  i.e.,  defined  by 
dedicated  groups  of  computer  program  instructions.  This  means  that  checking  a function 
with  input/output  tests  like  those  used  with  an  analog  system  will  not  necessarily  verify  that 
the  function  and  associated  hardware  is  operable  for  all  states  (e.g.,  amplitude/rate 
conditions)  of  the  function.  The  piece  parts  are  not  viewed  as  continuous  operating  devices 
dedicated  to  the  function,  but  a multitude  of  piece-parts  which  may  vary  for  each 
computational  pass  in  processing  the  input/output  relationship  of  the  function. 

Because  of  the  operational  differences  between  the  analog  and  digital  systems 
presented  above,  it  was  judged  that  a functional  flow  diagram  of  the  hardware  alone  could 
not  be  used  as  the  primary  reference  in  conducting  a FMECA.  The  study  approach  taken  in 
the  FCD  task  was  to  use  the  overall  system  redundant  configuration  to  direct  the  FMECA 
effort.  Two  levels  of  investigation  become  apparent  relative  to  an  overview  of  the  system 
redundant  architecture.  The  first  level  concerns  itself  with  the  channel  cross-tie  points.  Each 
intertie  between  the  channels  (involving  both  hardware  and  software)  must  be  analyzed  to 
determine  whether  a failure  mode  in  one  channel  or  within  the  cross-tie  interconnecting 
harness  could  encumber  the  operation  of  more  than  one  channel.  After  the  intertie  points 
have  been  checked  for  design  integrity  and  failure  mode  performance,  the  second  level  of 
investigation  must  be  completed.  This  deals  with  determining  whether  latent  failure  points 
exist  within  single  channel  elements  which,  when  combined  with  a detectable  system  failure, 
can  encumber  more  than  the  operation  of  a single  channel.  The  results  of  both  levels  of 
investigation  are  combined  in  developing  appropriate  preflight  test  requirements. 
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4.0  COMPUTATIONAL  ELECTRONICS  FMECA  AND  PREFLIGHT 
TEST  REQUIREMENTS 
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The  system  configuration  can  be  separated  into  major  functional  blocks  as  illustrated 
i:>  figure  3-1 . This  section  summarizes  the  computational  electronics  subsystems  (analog, 
incremental  digital,  and  whole-word  digital)  failure  mode  studies  and  preflight  test 
requirements.  The  discussion  on  each  subsystem  presents  a review  of  the  system’s 
redundancy  operation,  results  of  the  failure  modes  analysis,  and  specific  tests  required  fora 
preflight  integrity  check.  The  overall  preflight  test  mechanization  approach,  which  includes 
the  subsystem  integrated  with  the  peripheral  hardware  of  the  application  model,  is 
presented  in  section  S.O. 

A complete  detailed  failure  mode  analysis  was  not  made  on  each  subsystem  since 
neither  the  application  model  nor  the  subsystems  were  part  of  a prototype/production 
development  effort.  The  intent  of  the  information  presented  is  to  provide  an  insight  into  the 
difficulty  and  complexity  of  such  investigations  relative  to  the  potential  of  a flight-critical 
digital  system. 

Detailed  descriptive  information  on  the  three  subsystems  hardware  designs  and 
comparative  operational  performance  is  presented  in  FAA-SS-73-2-1  (ref.  1)  and 
FAA-SS-73-2-2  (ref.  2)  FCD  task  reports. 


4.1  ANALOG  SUBSYSTEM 

The  analog  subsystem  is  a brickwall  triple-channel  system  design  utilizing  in-line 
monitors  for  failure  detection.  The  redundant  channels  of  the  analog  system  only  crosstie 
through  a hydromechanically  force  summing  point  at  the  output  of  redundant  electric 
command  servos.  Figure  4-1  illustrates  the  analog  application  model  configuration.  A failure 
mode  analysis  of  the  hydromechanical  elements  of  the  application  model  is  not  a part  of 
this  study,  only  the  associated  electronic  elements  that  are  involved  with  failure  detection. 
Since  ihe  analog  system  channel  monitoring  is  mechanized  essentially  at  a single  point  and 
associated  with  the  output  of  the  electric  command  servo  (ECS),  preflight  test  requirements 
involved  the  consideration  of  the  electric  command  servosystem  normal/failure  condition 
operation. 

The  application  model  analog  control  law  processing  electronics  consisted  primarily  of 
a piece-part  mechanization  of  the  HSAS  filter  functions,  built  up  on  a breadboard  level 
following  design  philosophy  put  forth  for  the  SST  (and  most  contemporary  aircraft)  analog 
circuit  designs.  The  circuits  were  laid  out  to  follow  the  functional  flow  diagram  of  the 
system  (fig.  4-2).  Such  a circuit  design  approach  permits  laboratory  verfication  or 
investigation  of  the  failure  mode  effects  of  opening  or  shorting  specific  components,  where 
the  components  can  be  directly  related  to  a parameter  within  the  functional  flow  diagram. 

4.1.1  Analog  Subsystem  Monitoring 

The  in-line  failure  detection  monitors  of  the  analog  system  are  located  with  the 
servodrive  electronics  (fig.  4-3).  A differential  pressure  sensing  transducer  across  the 
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FIGURE  4-1-ANALOG  APPUCA  TION  MODEL  CONF/GURA  TION 
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servoaciuator  provides  the  signal  used  for  both  failure  monitoring  and  servoequalization. 
The  sensor  pickoff  is  associated  with  a differential  pressure  (AP),  a pressure  relief  detent 
mechanism  that  opens  and  ports  fluid  across  the  servoactuator  when  the  AP  reaches  a 
predetermined  threshold.  This  hydromechanical  detent  action  limits  the  actuator  force  level 
relative  to  the  other  redundant  electric  command  servos.  The  AP  electrical  pickoff  is  used  as 
a feedback  signal  to  equalize  the  servocommands  through  both  proportional  and 
pseudointegration  (lag-hold)  signal  paths.  Equalization  is  required  to  balance 
normal  dynamic  and  static  system  tolerances  between  the  redundant  channels. 

Failure  monitoring  for  the  analog  system  has  been  subdivided  into  three  failure-state 
detection  areas;  dynamic,  static,  and  oscillatory.  Dynamic  and  oscillatory  failures  are 
monitored  directly  from  the  AP  detent  signal,  and  static  failures  are  monitored  downstream 
of  the  lag-hold  equalization  function  (fig.  4-3).  Both  the  dynamic  and  static  failure  detectors 
utilize  the  same  design  (fig.  44)  where  the  lag-hold  function  provides  an  integral 
accumulation  of  the  static  errors.  These  failure  monitors  register  a failure  when  the  input 
signal  exceeds  a specified  threshold  for  one  second.  Should  the  input  signal  exceed  the 
threshold  for  less  than  one  second,  the  time  delay  is  reset  as  the  signal  drops  below  the 
threshold.  The  oscillatory  failure  detector  was  designed  to  monitor  failure  states  that 
resulted  in  a servodetent  oscillation  of  greater  than  0.2  cps.  These  monitors  are  the  basis  for 
detecting  all  failures  within  the  analog  system,  sensors  through  servos. 

4. 1 .2  Analog  System  FMECA 

Failure  modes  and  effects  criticality  analysis  on  the  analog  system  followed  the 
systematic  approach  of  analyzing/testing  piece-part  hardware  failures  to  determine  their 
effect  on  the  system  performance.  Breadboard  circuits  of  the  computational  electronics 
were  physically  altered  to  represent  typical  failure  conditions.  Failure  modes  were  inserted 
into  the  system  while  the  system  was  operational  in  a closed  loop  laboratory  set-up  with  a 
simulated  airframe.  As  the  failure  modes  were  inserted,  the  failure  mode  response  was 
observed  from  two  viewpoints;  failure  detection  (assuming  the  monitors  had  not  failed)  and 
airframe  disturbance.  Detail  failure  mode  results  are  shown  in  tables  4-1  and  4-2. 

Figure  4-2  is  the  schematic  of  the  HSAS  filter  breadboard  circuit  (one  channel).  Each 
component  on  the  breadboard  was  failed  during  laboratory  testing.  The  capacitors  were 
tested  as  shorts  and  as  opens.  The  resistors  were  tested  only  as  opens  since  this  is  their 
primary  failure  mode.  Laboratory  testing  only  considered  total  failure  of  the  component;  no 
testing  was  done  based  on  component  degradation  (component  value  change  with  time). 
Failures  of  operational  amplifiers  were  considered  to  be  equivalent  to  passive  component 
failures.  An  opening  of  a downstream  resistor  is  like  an  operational  amplifier  failing  to  zero, 
and  an  opening  of  the  plus  (+)  grid  reference  resistor  is  equivalent  to  an  operational 
amplifier  failure  to  saturation. 

Test  results,  tabulated  in  tables  4-1  and  4-2,  define  hardover  (HO)  and  slowover(SO) 
failure  responses  based  on  whether  the  dynamic  or  static  failure  detector  (DFD  or  SFD)  was 
the  firet  to  register  the  particular  fault.  Faults  that  are  labeled  no  effect  (NE)  indicate  that 
the  failure  was  not  detected  by  any  monitor. 
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Laboratory  FMECA  results  confirmed  two  points.  First,  no  single  failure  created  a 
safety-of-flight  condition.  Second,  the  failures  that  were  not  detected  by  the  monitors 
produced  little  or  no  effect  on  the  airplane  dynamics.  The  analysis  and  test  did,  however, 
show  that  approximately  26%  of  the  computational  electronics  failures  (essentially  filter  i 

functions)  were  not  detected  by  the  monitors,  as  were  50%  of  the  failures  (passive  failures) 
associated  with  the  servosystem.  These  undetected  failures  could  accumulate  in  time  and 
ultimately  degrade  the  system’s  performance  or  be  detrimental  to  the  system’s 
safety-of-flight  failure  respond. 

Failures  not  detected  by  the  monitors  under  in-flight  conditions  are  classified  as  latent 
failures.  Such  failures  must  be  analyzed  to  determine  their  probability  of  occurrence  relative 
to  functional  test  verification  check  intervals,  to  satisfy  the  mission  success  criteria,  or  to  be 
designed  out  of  the  system.  Since  other  elements  of  the  HSAS  (sensors,  pilot  command  ! 

paths,  and  monitors)  possessed  failure  states  that  were  latent,  difficult  to  design  out,  and 
required  a preflight  functional  verification  check  before  each  flight,  no  attempt  was  made  to 
remove  the  computational  electronics  or  servo  latent  failures  through  redesign. 

4.1.3  Analog  Preflight  Test  Requirements 

The  SST  mission  success  criteria  required  that  the  full  complement  of  redundant 
system  elements  be  operational  at  dispatch.  As  a result  of  the  analog  system  FMECA 
studies,  specific  tests  were  required  and  postulated  that  would  clear  the  analog  system 
monitors  and  computational  electronics  latent  failure  states.  The  tests  were  defined  in 
detail,  and  their  creadibility  was  substantiated  in  the  laboratory.  However,  the  tests  were 
not  implemented  and  integrated  into  a working  preflight  test  operation  since  the  analog 
system  did  not  inherently  have  a means  of  administrating  the  test.  A complete  system 
preflight  test  organization  and  administration  operation  is  covered  in  section  5.0. 

The  analog  subsystem  preflight  test  requirements  could  be  satisfied  by  verifying  that 
the  monitors  were  operational  and  then  utilizing  the  monitors  to  verify  that  the 
computational  electronics  were  operational  (no  latent  failures  existed).  Thus,  two  test  series 
were  developed. 

4.1 .3.1  Analog  Subsystem  Monitors  Preflight  Test 

The  task  of  checking  the  monitors  required  adding  circuitry  to  control  the  state  of  the 
lag-hold  equalization  logic  as  a function  of  the  ECS  simulated  engage/disengage  state  and  to 
provide  a AP  detent  signal  negation  stimuli  upstream  of  the  monitors  pickoff  points  (fig. 

4-5).  A test  was  developed  to  be  operated  when  the  hydraulic  system  was  depressurized 
since  under  this  condition  the  AP  signal  was  a constant  5 V.  The  AP  signal  could  be 
systematically  negated  to  control  failure  conditions  to  the  in-line  monitors,  the  monitors 
response  checked  for  proper  response,  and  the  monitors  response  cross-checked 
channel-to-channel  to  further  verify  the  test  results. 

Figure  4-5  shows  the  time  dependent  preflight  test  sequenced  test  stimuli,  and  table 
4-3  indicates  the  function  checked.  In  general,  the  test  checks  that  the  dynamic,  static,  and 
oscillatory  failure  detector  (DFD,  SFD,  OFD)  monitors  will  trip,  that  the  DFD  and  SFD 
plus  and  minus  thresholds  are  proper,  and  that  the  OFD  is  frequency  dependent. 
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4. 1.3. 2 Analog  Computational  Electronics  Preflight  Test 


Filter  circuit  normal  operation  and  latent  failure  conditions  could  be  checked  by 
stimulating  the  rate  gyro  (input  sensor)  at  specified  fixed  frequencies  and  observing  that  the 
monitors  did  not  register  a failure.  By  producing  a 0.3-  and  0.5-Hz  square  wave  excitation 
into  the  analog  subsystem  electronics  (fig.  4-6),  all  pertinent  circuitry  could  be  validated.  • 

The  failure  states  that  were  labeled  from  the  FMECA  as  being  latent  were  retested  under  the 
system  excitation  conditions  just  mentioned.  All  were  detectable  by  the  OFD  except  for 
failures  of  the  operational  amplifiers  trim  resistors  (table  4-4).  Since  the  loss  of  the 
operational  amplifiers  trim  resistors  did  not  degrade  the  system’s  performance,  they  were 
not  a necessary  part  of  the  design. 

All  but  two  latent  failure  modes  could  be  detected  with  the  0.5-Hz  signal.  A 0.3-Hz 
oscillation  was  required  to  detect  a shorted  capacitor  in  the  B filter  (C4  of  fig.  4-2).  The 
other  latent  failure  was  the  control  column  electrical  input  resistor  (R51).  This  path 
required  a control  column  input  and  could  not  be  exercised  by  the  rate  gyro  excitation. 

4.2  DIGITAL  SYSTEM  FMECA  APPROACH 

The  analysis  and  prediction  of  failure  effects  for  a digital  system  appears  to  be  an  order 
of  magnitude  more  complex  than  that  associated  with  an  analog  system.  Whereas  an  analog 
mechanization  dedicates  hardware  to  a particular  functional  process,  the  digital  system 
efficiency  is  achieved  by  multiplexing  common  hardware  to  systematically  perform  all 
functions.  This  time  sharing  of  hardware  presents  a new  dimension  to  the  digital  system 
failure  analysis,  potentially  making  the  task  easier  or  harder  depending  on  the  circuit 
utilization.  Processing  (multiplexing),  timing,  and  control  circuits  can  introduce  failure 
modes  that  are  both  event  and  time  dependent.  The  following  discusses  the  various  digital 
system  circuit  types  and  attempts  to  point  out  the  nature  of  their  failure  modes. 

If  we  exclude  those  circuits  in  a digital  system  whose  signal  flow  is  analog  in  nature 
(input  signal  conditioners,  and  output  sample  and  hold  devices),  we  can  categorize  the 
remaining  digital  circuits  as: 

• Combination  logic 

• Clocked  sequential  logic 

• Asynchronous  sequential  logic 
4.2.1  Combinational  Logic 

Combinational  logic  circuits  are  those  circuits  that  contain  no  memory  and  have  a 
truth  table  whose  output  is  directly  related  to  the  inputs.  These  circuits  can  be  either  * 

discrete  components  (resistors,  diodes,  transistors,  etc.),  or  integrated  circuits  refered  to  as  a 
a chip.  If  the  logic  is  built  on  an  integrated  chip,  the  FMECA  analyst  may  not  be  able  to 
find  out  precisely  how  the  chip  is  constructed.  The  same  functional  design  by  different 
manufacturers  may  have  different  failure  modes  depending  upon  the  crystal  line  structure 
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FIGURE  4-6—HSAS  ELECTRONICS  PREFLIGHT  TEST 


upon  which  the  circuit  has  been  developed.  In  many  cases,  these  logic  circuits  will  have 
internal  (relative  to  the  boundary  about  which  the  analysis  is  taking  place)  failure  modes 
that  will  either  fail  the  output(s)  high  or  low,  or  change  the  truth  table  of  the  output 
relative  to  the  input.  Thus,  the  FMECA  of  combinationed  logic  circuits  must  be  conducted 
by  determining  the  system  response  relative  to  postulated  truth  table  changes.  In  general, 
combinational  logic  circuits  can  be  represented  by  a box  with  n inputs  und  m outputs  as 
shown  in  Figure  4-7.  The  truth  table  for  this  logic  circuit  will  have  2n  rows  and  n + m 
columns.  There  are  m x 2n  possible  one  bit  variations  to  the  truth  table.  If  any  or  all  of  the 
m output  bits  are  considered  to  change  for  any  row,  then  there  are  2n  x (2m  -1)  possible 
changes  that  must  oe  investigated  for  an  exhaustive  failure  modes  analysis  by  the  truth  table 
approach.  For  a small  combinational  logic  circuit  of  three  inputs  and  two  outputs,  there 
would  be  2^  x (2-  -1)  = 24  possible  truth  table  changes  that  would  have  to  be  investigated 
for  an  exhaustive  truth  table  failure  modes  analysis.  Thus,  exhaustive  analysis  can  become 
very  costly  for  large  combinational  logic  circuits.  Even  so,  circuits  that  are  built  upon  chips 
where  the  analyst  does  not  know  how  the  circuit  logic  is  built  up,  the  truth  table  approach 
may  be  the  only  way  of  being  certain  that  all  possible  failure  modes  have  been  considered. 
Special  combinational  logic  circuits,  which  are  constructed  of  Nand  and  Nor  gates,  however, 
can  often  be  effectively  analyzed  by  considering  the  inputs  and  outputs  of  each  gate  to  have 
failed  high  or  low.  This  approach  can  be  simpler  than  the  truth  table  analysis  since  it  does 
not  always  require  investigating  all  possible  combinations  that  will  fit  into  the  truth  table, 
but  only  requires  investigating  failures  that  can  occur  in  the  specified  circuit. 

4.2.2  Clocked  Sequential  Logic 

Clocked  sequential  logic  circuits  contain  combinational  logic  and  memory  circuits 
(usually  flip-flops  (F/F’s))  and  are  wired  together  to  process  sequential  information.  The 
outputs  of  a sequential  logic  circuit  not  only  depend  on  the  present  set  of  inputs,  but  also 
depend  on  the  state  of  the  circuit  before  it  went  through  its  last  change.  In  general,  a 
sequential  circuit  has  as  many  binary  state  variables  as  it  has  memory  devices;  i.e.,  F/F’s.  If  a 
circuit  has  n binary  state  variables,  then  it  will  have  a maximum  of  2n  states  it  can  transition 
to.  The  functioning  of  a clocked  sequential  circuit  can  be  described  by  a state-transition 
table  or  state-transition  diagram,  just  as  the  functioning  of  a combinational  logic  circuit  can 
be  described  by  a truth  table.  Failures  in  the  clocked  sequential  circuits  can  occur  either  in 
the  combinational  logic  or  in  the  memory  devices.  Failures  in  the  clocked  sequential  circuits 
will  cause  changes  in  the  state-transition  diagram.  The  following  is  an  example  of  how  a 
state-transition  diagram  can  be  used  as  an  aid  for  conducting  the  FMECA  on  a clocked 
sequential  logic  circuit. 

Consider  the  shift  register  signal  shaping  circuit  shown  in  figure  4-8.  The  circuit 
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FIGURE  4-7-GENERALIZED  REPRESENTATION  OF  COMBINATIONAL  LOGIC  CIRCUIT 
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FIGURE  4-8-EXAMPLE  OF  A CLOCKED  SEQUENTIAL  LOGIC  CIRCUIT 


Two  possible  stable  modes  of  operation  exist  for  this  circuit.  One  mode  has  a period  of  six 
clock  cycles,  producing  a one  only  once  during  the  period.  The  second  mode  has  a period  of 
two  clock  cycles,  producing  an  output  of  alternating  ones  and  zeros.  These  modes,  as 
developed  from  the  above  state-transition  matrix,  can  be  illustrated  by  the  following 
diagrams. 
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In  order  to  effect  the  mode  desired,  logic  would  have  to  be  added  to  the  circuit  to 
initialize  the  flip-flops  to  a particular  modes  state  as  part  of  the  circuits  power-on  cycle. 

Figure  4-9  presents  the  failure  mode  state-transition  matrices  for  failures  associated 
with  the  third  flip-flop  (F/F  3)  of  the  subject  circuit.  From  looking  at  these  failure  analysis 
examples,  two  observations  can  be  made.  First,  even  though  this  circuit  is  rather  simple, 
there  are  a large  number  of  failure  modes  that  may  have  to  be  investigated.  Only  7 of  1? 
possible  cases  are  illustrated  for  only  one  device  in  the  circuit.  Second  failures  can  exist 
within  a circuit  analysis  boundary  such  that  the  output  is  not  necessarily  stuck  at  zero  or 
one,  but  may  continue  to  produce  periodic  functions.  Failure  mode  criticality  of  these 
failures  can  only  be  evaluated  by  analyzing  the  downstream  circuits  response  to  the  failure 
states  produced  (a  nontrivial  task). 

4.2.3  Asynchronous  Sequential  Logic 

Asynchronous  sequential  logic  circuits  contain  clocked  sequential  logic  circuits.  The 
latter  are  provided  with  clocking  signals  extraneous  of  the  circuit  boundary.  The 
asynchronous  circuits  process  through  a state-transition  on  a conditional  basis  as  a function 
of  the  input.  These  circuits  generally  appear  as  interfaces  between  nonsynchronized 
processes.  One  of  the  outputs  from  this  type  of  circuit  generally  is  an  interrupt  that  is 
utilized  to  inform  a processor  that  it  has  information  (data)  available  for  another  processor. 
The  ICPS-723  does  not  contain  any  of  this  type  of  interface  relative  to  our  laboratory 
study.  The  WWCS,  discussed  in  section  4.4,  does  contain  this  type  of  interface,  and  it  will  be 
dealt  with  in  that  section  of  the  document. 

Fortunately,  digital  systems  are  usually  put  together  with  relative  simple  building 
blocks.  The  task  in  conducting  the  FMECA  is  to  thoroughly  understand  each  of  these 
building  blocks  and  how  they  Fit  together  to  build  the  system,  and  then  describe  the  effects 
of  the  failures  of  each  building  block  on  the  system  operation. 
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FIGURE  4-9 -FAILURE  MODES  OF  F/F  3 (REF.  FIG.  4-8  CIRCUIT) 


The  use  of  hand  analysis  tools,  as  discussed  in  the  preceding  paragraphs,  can  become 
unwieldy,  laborious,  error  prone,  and  eventually  impractical  as  logic  circuits  under  analysis 
increase  in  complexity.  To  augment  the  hand  analysis,  failure  studies  were  accomplished 
using  a Boeing  special  computer  simulation  facility.  This  simulator  was  developed  to  handle 
the  analysis  of  logical  failure  modes  in  large  digital  circuits.  The  simulator  is  a combination 
of  hardware  and  software  with  the  following  capabilities: 

• High-speed  logic  level  simulation  capability  including  propagation  delays 

4 

• Register  level  simulation  language,  which  providos  a convenient  medium  for 
controllingand  monitoring  the  logic  level  simulation  and  concurrent  register  level 
simulation  of  interfaces  with  other  equipment. 

• Modular  description  of  simulation  problems  allowing  the  user  to  separately 
describe  black  boxes  or  subsystems,  and  constructing  their  interface  at  simulation 
time. 

Further  definition  of  the  computer  simulator  is  given  in  Boeing  document  D25-7 1060-1 , An 
Introduction  to  the  Computer  Simulator  (ref.  4). 


4.3  INCREMENTAL  CONTROL  PROCESSOR  SUBSYSTEM  (ICPS) 

The  ICPS  application  model  test  configuration  was  functionally  the  same  as  the  analog 
subsystem  with  the  exception  that  the  trim  command  logic  was  placed  within  the  ICPS  and 
thus  removed  from  the  simulation  (fig.  4-10).  Unlike  the  analog  system  brickwall 
organization,  the  ICPS  utilizes  cross-channel  information  exchanges  as  part  of  the  systems 
basic  redundancy  operation.  In  this  configuration,  (fig.  4-11),  input  sensor  signals  are 
converted  to  an  appropriate  digital  format  and  sent  immediately  to  the  other  channels  for 
signal  selection  processing.  Two  other  cross-channel  data  exchanges  took  place  following  the 
input  signal  selection  process  before  commands  are  passed  on  to  the  servo-subsystem.  The 
electric  command  servosystem  is  identical  to  that  used  in  the  analog  study,  only  here  the 
servomonitoring  is  accomplished  by  cross-channel  comparisons  as  opposed  to  the  in-line 
approach  used  in  the  analog  configuration. 

Since  the  ICPS  mechanization  has  cross-channel  interconnections  upstream  of  the 
hydromechanical  force  summing  point,  the  first  line  of  failure  mode  analysis  must  deal  with 
evaluating  these  interfaces.  Figure  4-12  illustrates  the  functions  of  the  cross-channel 
information  exchanges.  One  series  of  cross-channel  processes  relates  only  to  control  law  data 
while  another  two  are  associated  with  the  redundant  system’s  timing  and  control 
synchronization.  Each  cross-channel  exchange  of  information  is  accompanied  by  a signal 
voter  (selector)  and  a monitor.  The  purpose  of  the  voter  is  to  prevent  (block)  upstream 
failures  from  propagating  errors  into  downstream  functions.  Since  the  ICPS  is  time 
synchronized  on  a 1 Msec  bit-time  level,  and  the  cross-channel  interface  is  mechanized  using 
a serial  transmission  buss,  the  voters  are  simple  majority  logic  circuits  providing  a two  out  of 
three  bit  selection. 


FIGURE  4- 10-1  CPS  APPL ICA  TION  MODEL  CONFIGURA  T/ON 


FIGURE  4-12-ICPS  CROSS-CHANNEL  INTERFACES 


The  positioning  of  the  cross-channel  ties  within  the  ICPS  was  to  separate  major 
functional  blocks  (analog  to  digital  A/D),  signal  selection,  control  law  processing,  and  digital 
to  analog  (D/A)  and  to  provide  primary  LRU  failure  isolation.  The  intent  was  to  provide  a 
maximum  number  of  failure  success  paths  without  an  inordinate  amount  of  hardware 
complexity. 

The  timing  and  control  crossties  provide  the  logic  for  power-on  initial  system 
synchronization  and  a distribution  of  the  basic  clock  signal  to  permit  LRU  functional 
isolation.  The  ICPS  utilizes  an  active-standby  clock  fail-operational  scheme  where  the 
system  operates  with  reference  to  a primary  clock  and  switches  over  to  a secondary  clock  if 
the  primary  clock  fails.  This  design  is  a key  area  of  concern  relative  to  the  FMECA  because 
it  involves  a common  thread  function. 

One  other  cross-channel  interface,  the  failure  status  display  logic  transmitted  to  the 
system  status  and  control  unit,  exists  in  the  ICPS  configuration.  This  interface  is  not  an 
exchange  of  information  but  can  be  visualized  as  an  extension  of  each  channel  housed  in  a 
single  LRU.  The  only  direct  tie  of  this  cross-channel  link  is  at  the  functional  failure  lamp 
indicators  that  display  the  failure  state  at  each  voting  node  (fig.  4-1 3).  Each  channel’s  lamp 
driver  is  wire  ORed  to  the  functional  lamps  indicating  function  first  and  second  failure 
status;  i.e.,  clock,  iteration  reset,  output  voter,  etc.  This  interface  was  lightly  treated  in  the 
FMECA  study  since  the  appropriateness  of  the  design  (as  opposed  to  a lamp  per  channel) 
was  not  evaluated. 

In  the  FMECA  evaluation  of  all  of  the  cross-channel  circuits,  the  boundary  about 
which  a functional  analysis  is  constructed  must  be  chosen  with  care.  In  fact,  the  boundary 
must  be  to  some  degree  a variable  in  the  study.  A fixed  boundary,  improperly  chosen,  may 
hide  potential  failure  states  relative  to  a system  single  point  failure.  In  conducting  the  clock 
and  majority  logic  voter/monitor  FMECA’s,  independent  studies  were  made  to  evaluate  the 
designs.  The  results  were  not  identical  as  a result  of  the  individuals  se'ection  of  the  hardware 
functional  boundaries.  A comparison  of  the  efforts  brought  out  the  significance  of  the 
above  procedural  statement. 

4.3.1  ICPS  Monitoring 

The  primary  monitoring  principle  utilized  within  the  ICPS  is  cross-channel 
comparisons.  There  are  two  functional  interface  partitions  that  can  be  drawn  relative  to  this 
monitoring.  The  first  is  that  associated  with  the  redundant  elements  external  to  the  ICPS. 
This  monitoring  works  in  conjunction  with  the  input  signal  selection  process,  and  in  the  case 
of  the  application  model,  monitors  the  column  input,  pitch  rate  sensor,  manual  trim 
commands,  and  parameters  of  the  ECS  (i.e.,  ECS  position,  negator  position,  AP  detent  and 
equalization  signals).  The  second  is  associated  with  the  redundant  elements  internal  to  the 
ICPS,  essentially  the  monitors  related  to  the  majority  logic  voters  within  the  ICPS  hardware. 
In  addition  to  the  cross-channel  monitors,  some  in-line  monitors  exist  that  check  memory 
parity,  arithmetic  overflow,  and  power  supply  operation. 


The  cross-channel  failure  monitor  associated  with  the  input  signal  selection  process  is 
illustrated  in  figure  4-14.  For  each  set  of  input  signals,  the  monitor  function  can  establish 
which  signal  will  be  passed  on  to  the  control  law  computations  (median,  average  of  two,  or 


FIGURE  4- 13.— I CPS  FAILURE  STA  TUS  ORGANIZA  TION 
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single  selected).  Several  parameters  within  the  failure  detection  logic  of  the  monitor  are 
programmable  for  each  input  sensor  set.  These  parameters  include  filter  time  constants  (lag 
and  washout),  threshold  level  detection  at  the  output  of  the  filters,  and  allowable  iteration 
counts  above  the  threshold  before  a failure  is  registered.  Under  normal  usage,  the  signal 
selection/failure  detection  function  is  used  as  a median  selection  switching  to  the  average  of 
two  following  first  failure.  Forced  utilization  of  a specific  signal  input  defeats  the 
monitoring  function. 

The  monitor  associated  with  the  1CPS  majority  logic  voter  points  is  shown  in  figure 
4-1  5.  This  monitor  will  register  a failure  if  any  difference  exists  on  the  data  input  for  more 
than  500  ns.  The  monitor  provides  local  first  and  second  failure  status  information.  The 
registration  of  a failure  can  be  removed  without  disturbing  the  voting  function  by  activating 
a reset  command.  If  the  failure  persists,  the  monitor  will  again  register  that  fact. 

4.3.2  ICPS  FMECA 

Since  the  1CP-723  triple-channel  system  was  designed  as  a bit-for-bit  synchronized 
subsystem,  the  timing  and  control  structure  in  each  channel  anticipates  data  from  the  other 
channels  at  precise  instances  in  time.  Thus,  the  design  of  the  cross-channel  interfaces  does 
not  contain  interrupt  or  transmitter /receiver  control  information.  If  a receiving  channel  does 
not  get  the  anticipated  data  from  one  of  the  other  channels,  it  simply  flags  the  errant 
channel  as  failed. 

Appendix  A contains  the  FMECA  data  on  the  ICPS.  Information  presented  in  this 
appendix  is  placed  in  the  order  of  its  criticality  with  respect  to  assessing  the  ICPS 
fail-operational  design  integrity.  The  order,  was  arrived  at  by  separating  the  ICPS  into 
subsystem  functional  blocks  and  making  a judgement  as  to  their  FMECA  level  of  interest 
(i.e.,  cross-channel  paths  or  latent  fault  potentiality).  The  functional  blocks:  are: 

• Redundant  clock 

• Majority  logic  voter/monitor 

• System  failure  status  logic 

• Sensor  signal  selection  and  failure  detection 

• Input/output  circuitry  and  timing 

• Computer  unit  processing  electronics 

The  first  four  items  are  classified  as  level  one  failure  mode  functions  because  they 
involve  cross-channel  data  paths.  The  last  two  items  are  second  level  failure  mode  functions 
because  they  represent  circuitry  between  voting  nodes  and  must  be  checked  to  determine 
their  potential  latent  failure-mode  states.  In  analyzing  ICPS  failure  modes,  an  appropriately 
monitored  downstream  voter  (hydromechanical  subsystem)  was  assumed. 
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FIGURE  4- 15.  —MAJOR I TY  LOGIC  VOTER  FAILURE  MONITOR 
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4.3.2. 1 Level  One  Functions 

The  circuit  diagrams  associated  with  each  level  one  function  were  studied  to  gain  the 
circuit/function  understanding  required  to  determine  the  function’s  significant  hardware 
boundary.  New  drawings  were  then  prepared  that  grouped  the  circuit  details  into  the 
established  functional  boundary,  and  a systematic  failure  mode  analysis  began.  Because  the 
FCD  task  was  not  directed  at  developing  a prototype  or  production  system,  the  FMECA 
depth  was  carried  to  a level  that,  for  some  items  studied,  only  provided  an  insight  into  the 
failure  mode  nature  of  the  specific  circuit/function.  Several  key  areas,  however,  were 
covered  in  substantial  detail  (e.g.,  the  clock  and  majority  logic  voter  functions).  These  areas 
exemplify  the  technical  differences  between  a digital  and  analog  system. 

The  following  is  a summary  of  the  level  one  functions  FMECA  results. 

Redundant  Clock 

The  1CPS  fail-operational  clock  detail  description  and  failure  mode  analysis  is 
presented  in  section  A.l.  The  clock  circuits  were  considered  a key  area  to  be  investigated 
because  the  design  was  an  active  standby  operation,  an  operation  (function)  always  suspect 
relative  to  having  a single  failure  mode  which  may  inhibit  the  switch  over  to  the  standby 
elements  when  the  active  elements  fail. 

Thi.  ICPS  redundant  clock  scheme  utilizes  a primary /secondary  oscillator  configuration 
where  the  primary/secondary  clock  signals  are  routed  to  each  of  the  ICPS  interface  units  via 
external  wire  harness  (ships  wiring)  paths.  Both  signals  are  independently  monitored  in  each 
channel.  If  the  primary  clock  signal  fails,  the  secondary  clock  will  be  switched  in.  The  design 
integrity  of  the  circuit  appeared  to  rest  with  the  ability  of  the  clock  monitor  to  detect  all 
failures.  Rather  than  determining  the  clock  signal  generator  circuit  failures,  the  failure  mode 
study  began  with  investigating  the  monitor  to  determine  if  there  were  any  postulated  failure 
states  that  the  monitor  could  not  detect.  If  none  could  be  found,  then  one  does  not  have  to 
investigate  in  detail  the  clock  logic  failure  states. 

The  analysis  of  the  primary  clock  signal  monitor  discovered  that  there  was  a failure 
situation  whereby  the  monitor  would  not  detect  a particular  clock  waveshape  change.  This 
failure  situation  would  permit  the  loss  of  the  primary  clock  signal  without  detection;  thus, 
the  secondary  clock  signal  would  not  be  switched  in,  and  the  system  woulJ  be  without  a 
clock  signal  (total  system  going  dormant  from  a single  failure). 

As  a result  of  this  analysis,  the  clock  waveshaping  circuit  had  to  be  looked  at  to 
determine  if  a potential  failure  mode  existed  that  would  result  in  this  waveshape  change  not 
detectable  by  the  monitor.  Such  a failure  state  was  discovered,  providing  a device  failed 
during  a specific  time  interval  of  the  waveshaping  circuit’s  periodic  operation.  Even  though 
the  specific  device  failure,  coupled  with  the  specific  time  period,  could  be  shown  to  have  a 
low  probability  of  occurrence,  the  waveshaping  circuit  was  reviewed  to  determine  if  a design 
change  could  obviate  the  failure  mode. 

A design  change  was  developed  that  would  remove  the  discovered  failure  state 
possibility.  This  change  was  incorporated  into  the  ICPS  hardware.  Not  only  did  the 


43 


modified  circuit  remove  the  potential  failure  mc.de,  but  with  prudent  selection  of 
components,  could  reduce  the  waveshaping  circuitry  to  one-third  of  the  former  design. 

Majority  Logic  VoterjMonitor 
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The  cross-channel  data  voter  and  its  associated  monitor  were  the  next  area  of  concern. 
Since  this  signal  interface  required  electrical  crossties  between  the  redundant  channels,  the 
circuits  become  suspect  for  having  failure  states  that  could  propagate  from  one  channel  to 
another  in  a daisy-chain  fashion,  or  for  having  latent  failure  states  that  result  in  a 
simultaneous  first/second  failure  situation.  Results  of  the  failure  mode  analysis  showed  that, 
of  the  possible  failure  states,  70%  of  the  voter  failures  and  65%  of  the  monitor  failures  go 
undetected  during  the  processing  of  normal  data  (channel  A = channel  B = channel  C). 
However,  if  the  incoming  data  could  be  manipulated  such  that  all  incoming  failure  state 
situations  were  simulated,  all  voter  failures  and  all  but  10%  of  the  monitor  failures  can  be 
uncovered.  Of  the  undetectable  monitor  failures,  none  represent  a serious  latent  failure 
mode  as  they  are  associated  with  parallel  redundant  circuits  which  drive  failure  status 
displays  (where  one  leg  of  the  redundant  path  would  most  likely  be  removed  in  a 
production  application). 

By  reviewing  the  voter/monitor  detail  description  and  FMECA  in  appendix  A.2,  it  can 
be  seen  that  for  this  relatively  small  circuit  (14  elements),  a complete  analysis  is  no  trivial 
task.  The  analysis  did  not  uncover  a design  weakness  that  could  be  removed  by  a design 
change,  but  pointed  out  that  the  voter/monitor  circuits  must  be  tested  to  insure  their 
integrity.  The  circuit  test  requirements  brought  out  in  the  analysis  become  test 
specifications  for  the  built-in-test/pre  flight-test  function.  No  electrical  failure  mode  could  be 
postulated  that  would  result  in  a daisy-chain  failure  mode  propagation.  This  included 
considering  the  possibility  of  shorting  a cross-channel  data  transmission  buss  to  ground  or  to 
any  power  voltage  level  that  would  exist  within  the  1CPS  wiring  interface.  Such  failure  state 
possibilities  were  only  treated  from  an  analysis  viewpoint  since  destructive  tests  were  not  a 
part  of  the  FCD  task  laboratory  work. 

System  Failure  Status  Logic 

The  system  failure  status  logic  functions  were  only  lightly  treated.  The  full 
implementation  of  these  functions,  as  well  as  system  control  functions  with  respect  to  the 
man/machine  interface,  is  very  mission/vehicle  dependent  and  goes  beyond  the  bounds  of 
the  FCD  task.  However,  the  design  utilized  in  this  program  does  represent  the  typical  nature 
of  such  logic  and  does  provide  some  insight  into  associated  circuit  failure  modes. 

Appendix  A.3  covers  the  system  status  logic  description  and  associated  FMECA.  In 
general,  the  operational  integrity  of  circuits  designed  to  annunciate  failures  cannot  be 
determined  until  the  circuit  is  requested  to  respond  to  a detected  system  fault.  Logic 
failures  cannot  undermine  the  fail-operational  capability  of  the  system  but  can  miscue  the 
flight  crew  as  to  the  status  of  the  system.  Potential  electrical  failures  (shorts  tc  ground  or 
shorts  to  power)  on  the  three-channel  system  static  logic  lines  which  end  up  in  close 
proximity  to  each  other  at  the  display  panel,  could  effect  system  failure  moding  if  the 
annunciating  logic  and  system  engage/disengage  logic  emanate  from  the  same  source.  These 
circuits,  in  general,  must  be  checked  through  built-in-test/preflight-test  operations  involving 
flightcrew  participation. 
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All  variable  signals  outside  the  1CPS  computing  subsystem  pass  through  the  signal 
selection/failure  detection  (SSFD)  function.  This  function  receives  data  from  all  three 
sensor  sets  (channels  A,  B,  and  C)  and  selects  a single  signal  for  each  variable,  which  is  then 
passed  to  the  system  computational  sections.  The  incoming  signals  are  cross-channel 
monitored  which  provide  sensor  failure  identification  and  signal  selection  modification 
(median-select  to  average-of-two)  when  a fault  is  registered.  A block  diagram  of  the  SSFD 
function  is  shown  in  figure  4-14.  The  SSFD  selected  signals  are  crossfed  to  the  other 
channels  of  the  system  on  a bit-for-bit  synchronized  basis,  monitored  and  passed  through  a 
majority  logic  voter. 

Two  somewhat  independent  FMECA  studies  were  made  to  investigate  the  SSFD 
circuits.  Neither  study  resulted  in  an  in-depth  FMECA  treatment.  The  first  study  began  by 
developing  a complete  circuit  level  breakdown  of  the  SSFD  functions.  This  entailed 
constructing  12  detailed  drawings,  where  each  drawing  covered  the  piece-part  makeup  of 
specific  subfunctions  within  the  SSFD  circuitry.  Specific  piece-part  failures  were  then 
postulated  and  the  drawings  were  used  to  determine  the  failure  propagation/manifestation. 
This  approach  soon  became  unmanageable  because  of  the  circuit  complexity  and  associated 
time  and  manpower  demands  it  placed  on  the  FCD  task  effort.  A second  effort  was 
therefore  initiated  to  look  at  the  SSFD  function  from  a top-down  functional  point  of  view. 
In  this  approach,  failures  were  postulated  on  a functional  level  and  a further  breakdown  of 
the  function  only  took  place  when  a failure  proved  to  compromise  the  SSFD  operation. 
Details  of  this  work  are  presented  in  appendix  A.4. 

From  the  investigations  that  were  made,  two  generalizations  became  evident.  First, 
since  the  SSFD  circuits  process  data  in  a serial  fashion,  failures  in  the  median  selection  logic, 
which  is  utilized  to  process  normal  data,  would  be  detected  at  the  downstream  majority 
logic  voter  monitor.  Second,  since  the  proper  operation  of  most  of  the  SSFD  monitor 
circuit  only  becomes  evident  when  an  upstream  failure  occurs,  this  circuit  is  prone  to  having 
latent  failures. 

It  is  easy  to  conclude  that  a functional  test  of  all  off-line  functions  must  be  conducted 
to  verify  the  operational  integrity  of  the  SSFD  monitor  circuits.  Off-line  functions  amount 
to  68%  of  the  SSFD  circuitry  (5%  associated  with  the  signal  selection  mode  switching  and 
63%  associated  with  the  monitor  functions).  Tests  were  derived  that  would  result  in 
checking  the  integrity  of  the  off-line  circuits  on  a preflight  test  basis.  In  fact,  for  the 
particular  mechanization  of  the  ICPS  SSFD  function,  all  off-line  circuitry,  except  for  the 
parity  logic  and  failure  latching  logic,  could  be  exercised  (tested)  during  unused  time  slots 
within  each  96  jisec  SSFD  processing  window.  Such  a test  could  be  implemented  as  an 
in-flight  background  process  and  would  check  the  lag/washout  computation  and  associated 
thresholds,  failure  count  and  associated  thresholds,  and  SSFD  signal  output  of  both  median 
and  average-of-two  for  all  combinational  states  of  the  three  incoming  signals.  Running  the 
complete  test  to  check  all  time  constant,  threshold,  and  failure  count  values  would  take 
approximately  1 min.  Test  failures  would  be  detected  by  the  majority  logic  voting/monitor 
node  downstream  of  the  SSFD  function. 
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4.3. 2.2  Second  Level  Functions 


Second  level  functions  associated  with  failure  modes  and  effect  analysis  are  functions 
from  a system  configuration  overview,  whose  failure  cannot  result  in  directly  compromising 
the  integrity  of  a system’s  fail-operational  design.  These  functions  are  associated  with  the 
system’s  processes  and  circuitry  that  rest  between  signal  selection  or  voting  nodes  and  do 
not  require  the  operation  of  adjacent  channels  to  perform  the  function  in  a normal  fashion. 
The  FMECA  conducted  on  these  functions  is  concerned  with  identifying  potentially  latent 
failure  states,  which,  when  combined  with  other  latent  failure  states,  could  result  either  in 
the  system  incorrectly  responding  to  a detected  failure,  or  in  the  system  not  detecting  a 
performance  degradation  that  could  create  a hazardous  situation. 

The  following  is  a summary  of  the  1CPS  second  level  functions  FMECA  studies. 
Inpiit/Gutput  Circuitry  and  Timing 

Input/output  circuits  transform  the  signals  between  the  outside  world  and  the  digital 
subsystem  into  compatible  formats.  The  analysis  of  these  circuits  follow  to  a large  extent 
the  analysis  methods  used  in  conducting  the  FMECA  for  an  analog  system.  Much  of  the 
circuit  is  dedicated  to  a specific  function  or  signal  path,  and  the  multiplexing  process  does 
not  alter  the  signal-path  processes  but  stages  (sequences)  signals  to  and  from  the  digital 
system  through  fixed  time  windows. 

Failures  in  the  input  analog  circuits  (i.e.,  demodulators,  prefilters,  etc.)  can  result  in  a 
passive  signal  path  (failed  to  zero),  which  may  be  difficult  to  detect  depending  on  the  failure 
detection  threshold  of  the  SSFD  function.  Such  potential  failures  will  require  in-flight 
maneuvers  at  a sufficient  level  to  uncover  the  dormant  signal  path,  or  an  appropriate 
preflight  test  to  verify  the  signal  path  integrity  prior  to  system  dispatch. 

Failures  of  the  A/D  converters  can  cause  all  incoming  signals  to  be  plus  or  minus  full 
scale  or  zero,  or  may  cause  specific  signal  level  conversions  to  be  wrong.  Failing  of  the  lower 
significant  bits  of  an  A/D  process  can  result  in  the  loss  of  signal  resolution.  Loss  of 
resolution  in  two  or  more  channels  could  allow  undesirable  airplane  performance 
degradation  if  the  signal  path  was  involved  with  the  stability  loop  of  an  unstable  or  lightly 
damped  airplane  dynamic  characteristic.  Detection  of  these  lower-level  bit  failures  may  be 
difficult  relative  to  the  selected  failure  thresholds  of  the  SSFD  function.  For  example,  if  the 
SSFD  monitor  threshold  was  set  at  5%  of  full  scale,  only  failures  in  the  four  or  five  most 
significant  bits  of  the  A/D  would  be  detected.  Thus,  75%  of  the  possible  bit  failures  in  a 
12-bit  A/D  may  fall  below  the  monitor  threshold. 

Signals  leaving  the  digital  subsystem  through  a D/A  converter  can  have  failure  induced 
degraded  resolution  like  that  produced  by  the  A/D  conversion.  Here  again  failure  detection 
is  predicated  on  the  downstream  monitor  threshold  value. 

Results  of  a cursory  failure  analysis  of  the  timing  logic  (circuits)  indicated  that  timing 
failures  will  generally  produce  massive  miss-data  management  that  would  be  detected  by  a 
number  of  system  failure  monitors.  However,  because  of  the  multiple  point  usage  of  specific 
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timing  logic,  it  is  difficult  to  conduct  a detailed  hand  analysis  of  the  failure  propagation 
effects.  Therefore,  it  was  recommended  that  failure  response  data  relative  to  the  major 
timing  source  logic  be  determined  through  laboratory  tests.  Since  the  timing  functions  are, 
in  general,  exercised  iteratively  as  part  of  the  1CPS  hardwired  executive,  any  failure  in  one 
channel  should  produce  an  out-of-sequence  operation  with  the  other  two  channels  and  thus 
be  subject  to  detection  by  the  majority  logic  voting  node  monitors.  Details  of  the 
input/output  and  timing  FMECA  are  presented  in  section  A.5. 

ICPS  Computer 

The  ICPS  computer  performs  the  computational  processes  associated  with  mechanizing 
the  control  law  equations.  Within  the  computer  subelements,  data  handling  is  a function  of 
software  controlled  parameters  (instructions).  As  a consequence,  there  may  exist  hardware 
elements  (data  paths)  that  may  fail  and  go  undetected  because  the  software  (resident 
program)  does  not  utilize  that  function  in  the  makeup  of  the  control  law  equations. 
However,  once  the  control  law  has  been  fixed,  the  computer,  because  of  its  multiplexed 
serial  operation,  is  essentially  monitored  by  the  output  majority  logic  voting/monitor  node. 
The  only  areas  that  contain  a potential  for  latent  failures  are  the  branching  operation  and 
initial  condition  operation.  The  latent  failures  associated  with  branching  involves  the  setting 
of  the  most  significant  bit  of  the  address  register  (the  location  where  most  branch  loops 
would  reside)  and  the  integrity  of  the  instruction  bits  residing  in  the  upper  reaches  of  the 
memory.  The  initialization  latent  failures  are  generally  cleared  (uncovered)  during  the 
computational  reset  operation  at  the  start  of  the  program  execution.  A detailed  discussion 
on  the  ICPS  computor  failure  analysis  is  presented  in  section  A.6. 

4.3.3  ICPS  Preflight  Test  Requirements 

As  in  the  case  with  the  analog  subsystem,  a number  of  hardware  failure  modes,  which 
can  go  undetected  during  the  processing  of  normal  data,  resides  in  the  ICPS.  These  circuits 
are  primarily  related  to  error  monitoring  functions  and  signal  paths  that  are  only  used  after 
the  detection  of  failures.  Therefore,  these  circuit  elements  need  to  be  subjected  to  a periodic 
test  or  preflight  check  to  establish  their  functional  integrity  or  be  redesigned  such  that  the 
failures  become  evident  when  they  occur.  It  is  impractical  to  redesign  a system  as  complex 
as  the  ICPS  with  an  intent  that  the  system  becomes  100%  self-monitoring.  Even  if  the  ICPS 
elements  could  be  monitored  in  such  a way  that  internal  latent  failure  states  could  not  exist, 
such  failures  will  exist  within  other  elements  of  the  flight-control  system.  Therefore,  a 
preflight  test  (or  system  test  of  some  nature,  inflight,  postflight,  periodic,  etc.)  must  be 
conducted  to  ensure  a high  level  of  confidence  (high  probability)  that  the  system 
(flight-critical)  is  operationally  sound.  The  following  discusses  the  integrity  check 
requirements  envisioned  for  a preflight  test  on  the  ICPS. 

The  incremental  computer  cannot  be  programmed  to  function  as  an  administrator  of  a 
preflight  test  operation.  Therefore,  the  tests  described,  to  a large  part  conceptual,  assume 
appropriate  test  administration  hardware.  However,  some  laboratory  tests  were  conducted 
using  the  ICPS  hardware  to  verify  specific  preflight-test  tests.  These  tests  are  described  in 
appendix  B.  A block  diagram  of  the  test  configuration  is  shown  in  figure  4-1 6. 
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Since  the  system  monitoring  is  the  key  feature  for  ensuring  system  operational 
integrity,  it  is  essential  that  the  validity  of  the  monitoring  system  be  established 1 in  the  initial 
iS  of  conducting  the  preflight  test.  The  FMECA  results  pointed  out  that  aU  posubfc 
La  combinations  were  required  on  MLV’s  to  clear  the  monitor  of  latent  failures  In 
addition  the  signal  selection/failure  detection  circuitry  operation  must  be  completely 
verified  If  built-in-test  circuits  were  part  of  the  subsystem  design,  a test  program  sequencer 
could  be  postulated,  which  would  exercise  all  monitoring  functions  This  would  include 
testing  the  parity,  timing,  power  supply,  and  overflow  monitors,  as  well  as  the  system  MLV 
and  SSFD  monitors.  Tests  of  these  items  would  fall  into  the  category  of  checking  the 

checker. 

Thus  with  these  considerations,  the  following  sequence  of  testing  events  were 
postulated: 

1)  All  electrical  and  hydraulic  power  on-system  disengaged  implies  computational 
reset  is  active 

2)  Engage  system-note  that  all  test  failure  indicators  are  out 

3)  Activate  ICPS  preflight  test-enables  the  test  program  sequencer  and  provides 
go/no-go  testing  of  all  monitors 

4)  Activate  peripheral  hardware  preflight  test-torque  gyros,  operate  column  (note 
elevator  position  plus  or  minus  full  throw),  operate  manual  trim  (note  tnm  up  or 
down  operation) 

To  test  whether  the  postulated  preflight  test  would  be  sufficient  to  uncover  system 
failures,  several  potential  failures  were  tested  in  the  laboratory.  For  each  of  the  failures 
tested,  an  adaptation  of  the  above  procedures  was  utilized.  Failures  that  were  known  to  be 
active  (i.e.,  sensor  hardovers)  were  omitted  from  the  testing  exercise. 

Categories  of  failures  that  were  exercised  included  input/sensor  failures,  cable 
disconnects,  and  computer  memory  faults.  In  general,  these  types  of  failures  were  all 
detectable  by  the  proposed  test.  Appendix  B contains  the  tabulated  results. 

As  expected  from  the  FMECA  analysis,  the  output  MLV  monitor  caught  pertinent 
program  memory  errors.  Those  memory  faults  not  detected  by  the  output  monitor  were 
ones  that  produced  no  change  in  the  data.  However,  these  faults  were  detected  by  the 
built-in  read  only  memory  (ROM)  parity  monitor. 

4.4  WHOLE-WORD  COMPUTER  SUBSYSTEM  (WWCS) 

The  WWCS  application  model  laboratory  configuration  was  essentially  the  sameasthat 
used  for  the  ICPS.  The  signal  selection  and  cross-channel  data  flow  within  the  WWC5>, 
however,  are  comparably  different  than  that  of  the  ICPS  (fig.  4-17).  Sensor 
signal-selection/failure-detection  is  processed  in  software,  and  the  computer  unit  (CU) 
interface  with  the  servo-subsystem  is  through  a line  replaceable  unit,  other  than  t e 
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computer  interface  unit  (C1U),  and  is  referred  to  as  the  servotransmitter  receiver  unit 
(STRU).  The  WWCS,  however,  does  have  bit-for-bit  cross-channel  data  transfers  ide  .tical  to 
that  found  in  the  1CPS.  In  addition  to  this  synchronous  data  transfer  interface,  the  WWCS 
has  the  ability  to  transfer  data  between  computer  units  under  central  processor  control 
through  a nonsynchronous  serial  digital  interface. 

Detail  illustrations  of  the  WWCS  cross-channel  signal  interface,  are  shown  in  figures 
4-18  through  4-21.  The  first  two,  which  show  the  CIU  and  STRL  input/output  signal 
interfaces,  are  identical  except  that  the  CIU  contains  the  fail-operational  clock  logic  where 
the  STRU  votes  the  clock  information  from  all  three  CIU’s.  Figure  4-20  shows  the  computer 
unit’s  synchronous  logic  interface  with  the  CIU  and  STRU.  The  significant  difference 
between  the  computer  unit  to  CIU  interface  and  computer  unit  to  STRU  interface  is  in  the 
number  of  computer  unit  output  transmission  paths.  There  exists  only  one  output  holding 
register/transmitter  for  transmitting  data  simultaneously  to  all  three  CIU’s;  three  output 
holding  registers/transmitters  exist  for  transmitting  data  simultaneously  to  the  three  STRU 
channels.  Thus,  data  that  are  being  transmitted  to  the  STRU  can  be  individually  tailored  for 
each  STRU  channel. 

Figure  4-21  shows  the  WWCS  cross-channel  interface,  which  is  totally  different  from 
any  within  the  ICPS.  This  interface  permits  a direct  (under  central  processor  control) 
computer-to-computer  communication  link.  Its  control  (labelling),  as  well  as  data,  is 
involved  in  the  cross-channel  transmission.  Information  transmitted  via  this  route  can  gain 
the  attention  of  the  receiving  central  processor  through  the  use  of  interrupt  logic. 

4.4.1  WWCS  Monitoring 

Like  the  ICPS,  cross-channel  signal  comparisons  are  the  basis  for  WWCS  failure 
monitoring.  Unlike  the  ICPS,  however,  the  WWCS  combines  the  failure  state  information  for 
display  in  software  not  hardware  (fig.  4-22).  All  the  WWCS  failure  status  information  is 
placed  in  memory,  appropriately  combined  under  program  control,  and  transmitted  to  the 
system  status  and  control  unit  (SSCU)  for  failure  state  display.  Failure  status  information 
from  the  CIU  enters  the  computer  unit  through  a device  controller  under  central  processor 
control.  Failure  status  information  from  the  STRU  enters  the  computer  unit  via  the 
synchronous  logic  interface  and  gets  placed  directly  into  the  memory. 

First,  second,  and  local  failure  states  are  identified.  The  first  and  second  states  are 
generally  system  level  failures  and  are  primarily  derived  from  the  monitors  associated  with 
cross-channel  interfaces.  Local  failure  states  are  developed  by  combining,  where  possible, 
the  logic  of  the  first  failure  information  and  channel  failure  information  (parity,  power 
supplies,  etc.)  so  that  a channel  can  identify  that  the  fault  is  within  its  elements. 

The  synchronous  logic  majority  logic  voter/monitors  of  the  WWCS  are  identical  to 
those  used  in  the  ICPS  and  are  associated  with  intrasystem,  WWCS,  cross-channel  signal 
paths.  All  redundant  signals  entering  the  WWCS  are  monitored  using  a software  SSFD 
algorithm.  Since  software  from  the  FMECA  point  of  view  cannot  fail,  in  that  it  can  only 
respond  to  hardware  failures,  the  specific  WWCS  software  SSFD  used  will  not  be  described 
in  detail  here  (ref.  1).  However,  the  following  FMECA  results  do  point  out  the 
interrelationships  between  hardware  and  software  relative  to  failure  propagation  and 
protection. 
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4.4.2  WWCS  FMECA 

Methods  and  techniques  for  analyzing  the  WWCS  are  essentially  the  same  as  those  used 
on  the  1CPS  and  discussed  in  section  4.3.2.  Therefore,  failure  mode  study  discussions  on 
hardware  functional  subassemblies  common  to  the  1CPS,  such  as  the  redundant  clock, 
majority  logic  voter/monitor,  and  input/output  circuitry  and  timing,  will  not  be  repeated.  A 
key  area  that  is  discussed,  however,  relates  to  how  software  can  be  used  to  alleviate 
potentially  undesirable  failure  modes.  The  general  purpose  nature  of  the  WWCS  permits  a 
great  deal  of  flexibility  relative  to  altering  the  hardware/software  interface  in  light  of  failure 
mode  situation  awareness. 

Appendix  C contains  the  FMECA  investigation  data  relative  to  the  WWCS.  Information 
presented  in  the  appendix,  like  that  for  the  1CPS,  is  placed  in  order  of  its  ^sessed  cnticality 
with  respect  to  understanding  the  WWCS  fail-operational  design  integrity.  Thus,  the  FMECA 
discussion  is  divided  into  a level  one  area  of  investigation  covering  the  cross-channel 
interfaces,  and  a second  level  area  of  investigation  covering  the  potentiality  of  latent  failures 
in  the  redundant  channel  segments  between  cross-channel  communication  points. 

4.4.2. 1 Level  One  Functions 

Level  one  functions  for  the  WWCS,  over  those  common  to  the  ICPS,  are  the  device 
controller  cross-channel  data  link  and  the  servotransmitter/receiver  interface. 

The  device  controller  link  constitutes  a specific  cross-channel  (computer-to-computer) 
information  communication  path,  where  the  other  interface  is  associated  with  data  handling 
circuitry  between  major  line  replaceable  units  within  the  WWCS.  Therefore,  the  device 
controller  interface  FMECA  provides  an  insight  into  a general  class  of  asynchronous 
cross-channel  data  processing,  where  the  other  item  relates  specifically  to  the  WWCS  design. 

The  following  is  the  level  one  functions  FMECA  results. 

Device  Controller  ( Cross-Channel  Data  Link  and  SSCU  Interface) 

The  device  controller  cross-channel  interface  represents  a major  deviation  to  the 
bit-synchronous  majority  logic  voter/monitor  function  in  that  the  interface  control,  as  well 
as  the  data,  is  transferred  through  itus  communication  link.  The  central  processor  (CP) 
under  program  control  loads  and  initiates  execution  of  the  cross-channel  transmitter,  where 
the  signal  train  contains  the  control  information  to  enable  the  receiving  circuit  to  acquire 
the  incoming  data.  The  receiving  CP  under  program  control  can  fetch  the  incoming  data  at 
will  or  be  forced  to  retrieve  the  data  upon  its  arrival.  It  is  this  transmission/receiving  process 
which  must  be  scrutinized  in  order  to  determine  if  a failure  in  one  channel  can  affect  the 
operation  of  the  other  channels.  Since  servicing  the  receiver  involves  software,  the  servicing 
software  program,  as  well  as  the  interface  hardware,  must  be  clearly  understood  before  the 
failure  effects  of  the  device  controller  cross-channel  function  can  be  established. 

There  are  two  modes  in  which  the  WWCS  asynchronous  cross-channel  function  can  be 
utilized.  One  is  through  the  use  of  an  interrupt,  where  the  device  controller  directly  acquires 
the  attention  of  the  CP  when  the  receiver  has  been  loaded  with  incoming  data.  The  interrupt 


functionally  works  by1  forcing  jump  instruction  into  the  instruction  register  following  the 
completion  of  the  instruction  currently  being  executed.  The  address  portion  of  the  forced 
jump  instruction,  determined  by  which  device  controller  interrupt  has  occurred,  directs  the 
CP  to  the  starting  location  in  memory  for  the  appropriate  program  for  servicing  the 
associated  receiver.  In  essence,  the  mainstream  program  is  held  up  until  the  receiver  is 
serviced.  The  CP,  following  the  processing  of  the  receiver  routine,  is  returned  to  the 
mainstream  task  where  corrections  can  be  made  on  the  mainstream  data  as  the  program 
picks  up  at  the  point  from  which  the  interrupt  occurred.  The  second  mode  in  which  the 
cross-channel  function  can  be  utilized  is  upon  CP  (program)  demand.  In  this  mode,  use  of 
the  device  controller  interface  remains  strictly  under  control  of  the  mainstream  program. 
The  device  controller  interrupt  is  masked  (the  computer  can  be  programmed  to  ignore  an 
interrupt),  and  the  receiver  servicing  takes  place  when  the  mainstream  program  desires  the 
information  that  is  held  by  the  receiver. 

In  beginning  the  FMECA  of  the  device  controller  cross-channel  function,  it  becomes 
obvious  that  for  the  interrupt  mode  of  operation  a potential  single  point  system  failure 
could  occur  if  a transmitter  failure  held  the  attention  of  the  two  receiving  channels  such 
that  the  interrupt  routine  was  always  on  call.  This  could  be  overcome  either  by  having  a 
software  or  hardware  escape  capability,  (i.e.,  setting  a maximum  time  for  the  interrupt  to  be 
recognized),  or  by  avoiding  the  interrupt  mode  altogehter.  For  a flight-critical  system,  the 
latter  approach  appears  to  be  the  more  conservative  route. 

The  control  device  receivers  can  be  operated  in  the  put-and-take  (CP  controlled)  mode 
without  the  danger  of  a single  point  system  failure  hazard.  For  the  case  where  other  device 
controller  interface  functions  require  an  interrupt  mode,  (e.g.,  to  service  ground  support 
equipment),  the  hardware  design  would  have  to  accommodate  individual  masking  of  the 
device  controller  interrupt  function  (the  WWCS  device  controller  interfaces  utilize  a single 
interrupt  line). 

For  the  FCD  task,  the  WWCS  cross-channel  device  controller  interface  was  utilized  in 
the  noninterrupt  mode.  This  cross-channel  link  was  only  used  for  the  system  redundant 
synchronization  initialization,  associated  with  the  system  computational  reset  function. 
Thus,  the  interface  was  only  active  during  the  execution  of  the  mainstream  code,  which 
responded  to  the  computational  reset  command  discrete.  Even  though  this  WWCS  interface 
was  not  used  in  the  interrupt  mode,  there  still  exists  failure  states  that  could  compromise 
the  system  operation,  (e.g.,  latent  failures  in  the  interrupt  masking  logic).  Therefore,  future 
designs  will  have  to  be  critically  checked  for  their  possible  failure  modes,  which  will  have  to 
be  cleared  using  built-in  or  preflight-test  tests.  Details  of  the  device  controller  cross-channel 
FMECA  are  presented  in  section  C.  1 . 

The  WWCS  computer  unit  to  system  status  and  control  unit  is  another  system  interface 
where  a device  controller  is  used.  This  interface  design  does  not  include  an  interrupt  mode 
and  therefore  can  only  be  used  on  demand  (PUT  and  TAKE)  through  the  CP.  Both  the 
failure  display  transmitter  and  failure  status  receiver  (failure  status  discretes)  operate  under 
mainstream  code  control.  Any  active  failure  in  this  interface  is  readily  apparent  (computer 
held  in  computational  reset  or  lamp  display  locked  on).  The  most  prevalent  potential  latent 
is  to  have  the  error  reset  function  fail  to  on.  For  this  condition,  all  monitors  within  a 
channel  will  fail  to  register  (display)  a failure  state.  This  condition  can  arise  from  hardware 
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failures  or  through  software  errors.  Thus,  the  FMECA  results  support  the  requirement  that  a 
critical  analysis  must  be  conducted  on  both  the  hardware  and  software;  and  further,  that 
great  care  must  be  taken  in  making  software  changes  to  avoid  and  to  verify  that  software 
errors  are  not  entered  while  implementing  a software  change.  The  SSCU  FMECA  details  are 
covered  in  section  C.2. 

Servo  Transmitter/Receiver  Interface 

The  WWCS  computer  unit  to  STRU  interface  presents  a potential  hazard  for  level  one 
system  failures.  The  interface  provides  cross-channel  data  flow  from  each  computer  unit  to 
all  three  channels  of  the  STRU  and  from  each  channel  in  the  STRU  back  to  all  three 
computer  units;  therefore,  two  situations  exist  where  a single  channel  signal  is  feeding  a 
redundant  computational  string.  Going  from  the  computer  unit  to  STRU,  a potential  single 
point  failure  is  avoided  through  the  use  of  majority  logic  voter  functions.  However,  in 
analyzing  the  STRU  to  computer  unit  design,  there  does  exist  a potential  failure  mode  that 
could  compromise  the  fail-operational  design  of  the  WWCS. 

The  STRU  to  computer  unit  interface  is  a digital  serial  data  path  that  transports  eight 
16-bit  data  words  of  information.  Seven  words  are  associated  with  A/D  converted  variable 
signals,  and  one  word  is  used  for  discrete  and  failure  status  information.  The  variable  analog 
signals  are  converted  to  a 12-bit  digital  signal  accuracy  and  packed  into  the  lower  portion  of 
the  16-bit  transmitted  serial  word.  Each  data  word  is  simultaneously  received  by  all  three 
computer  units  and  placed  into  memory  via  the  synchronous  logic  interface  direct  memory 
access  operation.  With  this  design,  it  is  possible  to  develop  a failure  in  the  data  transmission 
circuitry  that  can  transfer  the  16-bit  data  word  askew  relative  to  the  computer  unit  receiving 
timing  window.  Since  the  STRU  interface  is  designed  to  receive  servocommands  tailored  to 
each  STRU  channel,  it  is  implied  that  each  computing  channel  would  utilize  servo  feedback 
data  in  its  raw  form;  i.e.,  nonsignal  selected  in  computing  the  STRU  channel  commands.  If 
the  above  failure  shifts  the  12-bit  data  into  the  16-bit  memory  location  such  that  the  signal 
significance  has  increased  or  the  sign  convention  is  altered,  a potential  exists  to  encounter  a 
computational  overflow  in  the  subsequent  processing  of  that  data.  Since  all  three  computer 
units  would  be  processing  common  data,  there  is  a possibility  that  the  single  signal  fault 
could  force  all  three  computers  erroneously  into  an  arithmetic  overflow  protection  routine 
or  other  subroutine  that  may  cause  the  system  to  lock  up.  For  such  a design,  precautions 
must  be  taken  in  hardware  or  software  to  mask  the  upper  bits  of  the  16-bit  data  word  or  to 
provide  reasonableness  tests  (or  cross-channel  comparisons)  on  the  data  to  ferret  out  failure 
states.  Again,  software  may  be  involved  in  providing  protection  against  undesirable  failure 
modes.  Detail  STRU  FMECA  results  are  presented  in  section  C.3. 

4.4. 2.2  Second  Level  Functions 

Some  second  level  FMECA  functions  of  the  WWCS  are  identical  to  those  in  the  ICPS. 
These  are  primarily  the  A/D  and  D/A  processes.  However,  failures  within  these  areas  were 
reviewed  to  determine  their  propagation  effect  into  the  downstream  function.  For  instance, 
if  an  averaging  signal  selection  algorithm  (in  software)  was  used,  lower  order  bit  failures  in 
the  A/D  process  would  be  passed  to  all  computer  units  and  would  influence  the  selected 
signal  value.  The  allowable  error  band  would  be  established  by  the  associated  SSFD  monitor 
thresholds. 
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The  other  WWCS  second  level  functions  investigated  were  the  synchronous  logic 
interface  (SLI),  memory,  and  central  processor.  As  previously  mentioned,  an  in-depth 
(exhaustive)  FMECA  study  was  not  conducted;  rather,  each  functional  area  was  looked  at  to 
gain  an  insight  into  the  function’s  latent  failure  potentialities  and  to  acquire  some  insight 
into  the  required  analysis  approach.  The  following  summarizes  the  FMECA  studies 
conducted  on  the  three  WWCS  functional  areas  just  mentioned. 

Synchronous  Logic  Interface 

The  SLI  is  a hardwired  function  that  processes  all  bit-for-bit  synchronous  logic  data 
into  and  out  of  the  computer  unit  memory.  Dedicated  memory  locations  are  allocated  to 
accommodate  the  incoming  and  outgoing  variable  or  discrete  information.  Since  the  SLI 
circuitry  is  active  in  nature  and  involves  a multiplexing  operation,  failures  within  this 
circuitry  tend  to  be  discoverable  just  from  the  processing  of  normal  data.  In  fact,  ..o  failure 
mode  could  be  uncovered  that  would  not  result  in  the  modification  of  incoming  or  outgoing 
signals.  Therefore,  faults  in  one-channel  SLI  would  result  in  placing  data  into  its  computer 
unit  memory  different  from  that  placed  in  the  memories  of  the  other  two  computer  units  or 
would  result  in  different  data  being  transmitted  from  the  faulty  computer  unit’s  SLI.  Errors 
on  the  input  data,  which  only  effect  the  lower  order  bits  (signal  resolution  degradation), 
may  not  be  detected  by  the  software  SSFD,  but  the  errors  would  ultimately  be  picked  up 
by  the  output  majority  logic  voter/monitors  located  in  the  STRU  and  CIU,  which  will 
detect  any  bit-for-bit  error  on  computer  unit  outgoing  data.  A more  detailed  SLI  FMECA 
discussion  is  presented  in  section  C.4. 

Memory 

The  WWCS  memory  is  builtup  utilizing  ferret  cores.  The  memory  is  used  to  store  the 
WWCS  operational  program  (execution  instructions  for  the  central  processor),  input  and 
output  variable  and  discrete  information,  program  constants,  and  intermediate  data  relative 
to  calculations  controlled  by  the  operational  program.  The  WWCS  memory  system  is  a 
destructive  read/restore  core  memory  with  a built-in  parity  monitor. 

The  memory  system  has  three  potential  latent  failure  areas.  The  first  is  whether  the 
parity  checker  checks  for  parity.  The  second  is  associated  with  the  loss  of  data  in  a core  cell, 
either  because  the  cell  magnetic  orientation  has  changed  or  the  cell  itself  has  cracked.  The 
third  involves  the  circuitry  that  must  respond  to  the  parity  error  detection.  Core  cell  errors 
can  only  be  detected  when  that  cell,  as  part  of  a program  word  in  memory,  is  exercised 
(read).  Therefore,  core  cell  failures  can  go  undetected  for  extended  periods  of  time  if  that 
portion  of  the  program  is  not  utilized  during  normal  system  operation;  e.g.,  if  the  program 
function  deals  with  the  system  operation  following  a system  failure.  Such  failures  can  be 
detected  by  exercising  a complete  memory  parity  check  as  part  of  the  preflight  test  or 
during  a running  background  (self-test)  program. 

Parity  error  detection  creates  an  interrupt  to  the  central  processor  that  forces  the 
computer  into  a memory  fault  routine  if  a higher  priority  interrupt  is  not  present.  Parity 
error  does  not  prevent  the  continued  processing  of  instructions;  i.e.,  recovery  from  a parity 
error  is  handled  in  software.  Following  the  servicing  of  one  parity  error  or  other  arithmetic 
fault  interrupts,  an  instruction  must  be  executed  which  clears  the  arithmetic  fault  logic.  The 


interrupt  structure  within  the  central  process  is  mechanized  such  that  only  when  there  is  a 
change  in  interrupt  status  between  instructions  will  the  program  actually  be  interrupted. 
Therefore,  if  the  clear  arithmetic  fault  instruction  is  not  processed  after  an  interrupt  has 
been  serviced,  successive  parity  failures  would  not  be  passed  on  to  the  central  processor. 
Further  details  on  the  memory  FMECA  are  presented  in  section  C.5. 

Central  Processor 

The  CP  is  made  up  of  circuits  that  control  the  interpretation  and  execution  of  the 
program  instructions  stored  in  memory.  The  instruction  interpretation  and  processor 
register  control  is  developed  through  read-only-memory  microprogramming.  As  the  details 
of  the  central  processor  circuitry  were  being  laid  out,  it  became  obvious  that  a bottoms-up 
(piece  part)  analysis  of  this  function  could  not  be  accomplished  with  the  resources  available. 
However,  experience  todate  has  shown  that  an  effective  FMECA  can  be  pursued  on  a 
functional  level.  Therefore,  an  analysis  of  the  WWCS  CP  was  conducted  based  on  a 
functional  level  study  referred  to  as  a middle-up  approach.  The  basis  for  this  approach  was 
to  look  at  the  CP  at  the  instruction  level  since  a general  purpose  digital  computer  is  nothing 
more  than  a device  for  sequentially  processing  given  instructions.  Each  instruction  can  be 
described  as  a series  of  operational  (functional)  steps,  where  each  step  can  be  subject  to  a 
failure.  Depending  on  the  hardware  design,  the  particular  step  failure  may  be  related  to  a 
failure-in-one  or  one-of-many  piece-part  elements  utilized  in  the  mechanization  of  that 
functional  step. 

The  failure  mode  analysis  can  be  conducted  in  general  relative  to  studying  each 
instruction  capable  within  the  CP  or  can  be  conducted  for  only  those  instructions  used  in 
the  operational  program.  Whichever  is  the  case,  the  failure  effect  part  of  the  analysis  must 
include  the  resident  software  program  in  order  to  ascertain  the  propagation  effect  of  the 
failure  mode.  A failure  state  for  each  instruction  step  would  then  be  classified  as  being 
immediately  detectable,  latent,  or  trivial.  Examples  of  the  various  failure  classifications  for 
given  instruction  steps,  from  the  study  conducted  for  the  FCD  task,  follow. 

One  step  of  the  MCP-701  central  processor  load  upper  register  (LDU)  instruction 
modifies  the  sign  adder  (SA)  indicator  bit  of  the  status  register.  A failure  in  this  step  was 
classified  as  trivial  if  the  significance  of  this  bit  was  not  utilized  by  any  other  instruction  of 
the  application  (operational)  program.  Another  step  in  the  LDU  instruction  is  to  address  a 
specified  memory  location  whose  content  is  to  be  placed  in  the  upper  register.  If  the  desired 
memory  location  is  not  selected  (step  failure)  and  the  data  in  the  wrong  memory  location 
does  not  correspond  identical  to  that  in  the  right  location,  the  step  failure  was  classified  as 
immediate  since  tracking  through  the  application  program  showed  that  the  failure  would 
result  in  an  output  command  different  from  the  other  two  processors.  This  difference  would 
be  detected  by  the  WWCS  output  MLV  monitors. 

An  instruction  step  failure,  which  was  classified  as  a possible  latent  failure,  was  one 
involved  with  the  multiply  (MPY)  instruction.  The  step  deals  with  multiplying  the  upper 
register  by  the  contents  of  a specific  memory  location.  Depending  on  the  multiply 
instruction  design  and  hardware  implementation,  a failure,  which  would  only  effect  a unique 
solution,  could  occur;  i.e.,  the  solution  of  a specific  number  in  the  upper  register  multiplied 
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by  a specific  number  in  memory  may  be  wrong.  For  a 16-bit  multiplier,  this  may  effect  only 
one  solution  out  of  2^  possible  solutions.  This  type  of  latent  failure  case  must  be  looked  at 
in  detail  by  analyzing  the  involved  hardware  or  by  defining  a background  self-test  routine, 
which  will  periodically  test  all  multiply  states. 


The  FMECA  exercise  conducted  on  the  WWCS  central  processor  is  prerented  in  section 
C.6.  Even  though  this  exercise  did  not  consider  the  entire  application  program  used  for  the 
FCD  task  it  was  concluded  that  the  middle-up  analysis  approach  had  merit,  and  should  be 
applied  in  a critical  system’s  FMECA  as  soon  as  the  system’s  hardware /software  definitions 

become  visible. 


4.4.3  WWCS  Preflight  Test 

One  of  the  primary  advantages  identified  with  a whole -word  (general  purpose)  digital 
processor  in  a flight-critical  control  system  application  is  its  potential  to  manage  an  overall 
system  test  with  a minimal  impact  on  hardware  additions.  However,  before  a processor 
system  can  be  relied  upon  to  administrate  such  a system  test,  it  must  first  be  able  to  ensure 
its  own  integrity.  For  the  WWCS  development  as  part  of  the  FCD  task,  a built-in-test  (BIT) 
feature  was  specified  that  would  functionally  establish  the  operational  integrity  of  the 
WWCS  fail-operative  design.  This  BIT  capability  was  to  check  those  elements  within  the 
WWCS  that  would  have  to  be  proven  operational  during  a preflight  test  (dispareh  test)  of  a 
flight-critical  system 

The  following  sections  provide  a summary  description  of  the  WWCS  BIT,  where  BIT 
refers  to  the  set  of  hardware/software  developed  within  the  WWCS  to,  under  Prog^n 
control,  establish  its  own  operational  integrity.  A basic  requirement  for  the  WWCS  BIT 
feature  was  that  the  BIT  function  had  to  perform  a self-test  on  the  WWCS  to  a level  which 
would  assure  that  the  subsystem  could  reliably  administrate  a pre flight  test  on  the  entire 
flight-critical  system.  Thus,  BIT  was  looked  upon  as  the  first  series  of  test  sequence  that  was 
to  establish  the  flightworthiness  of  the  flight-control  system. 


4.4.3. 1 BIT  Implementation  Overview 

The  structure  of  the  WWCS  (MCP-703  system)  and  the  nature  of  the  flight-critical 
system  application  problem  led  to  a fundamental  decision  to  implement  the  BIT  function 
wherein  all  computer  units  would  play  an  equal  role  in  the  BIT  processes.  This  decision  was 
founded  on  the  principle  that  all  computer  units  had  to  be  operational  to  achieve  a dispatch 
state  and  the  idea  that  tests  employing  the  system  redundancy  vs  tests  using  singular 
reasonableness  criteria  provided  the  greatest  level  of  test  success  confidence.  Therefore,  all 
computer  units  were  to  have  an  active  role  in  the  administration  of  BIT  and  were  to  interact 
(compare  test  success)  at  each  test  step.  The  BIT  implementation  philosophy  and  scope  are 
summarized  by  the  following  BIT  development  guidelines: 

• Testing  was  to  be  performed  in  all  three  channels  simultaneously. 

• All  processors  (computer  units)  were  to  play  an  equal  role  and  interact  at  each 
test  step. 


• All  WWCS  voters  and  their  associated  monitors  must  be  cleared  of  potential  latent 
failures. 

• A minimum  of  simplex  testing  should  be  employed . 

• The  design  should  entail  a minimum  of  operator  (flightcrew)  intervention. 

• Where  possible,  functions  tested  should  be  used  in  testing  other  functions. 

Basic  control  and  display  functions  to  operate  BIT  and  to  ultimately  operate  the 
preflight  test  program  were  placed  on  the  WWCS  SSCU.  These  functions  (fig.  4-23)  were 
designed  to  be  representative  of  those  functions  that  may  be  required  on  the  application 
vehicle’s  flightdeck.  They  consist  of  a rotary  switch  (fig.  4-23)  labelled  INTERLOCK,  a 
guarded  toggle  switch  labelled  INITIATE,  three  channel  NO-GO  indicators,  a test-in  progress 
numeric  display,  and  a push-to-cominue  button. 

The  Interlock  switch  controls  the  discrete  data  signal  paths  used  to  induce  failures  into 
the  WWCS  hardware/software.  The  function  is  representative  of  the  interlocks  that  would  be 
imposed  in  a production  implementation  to  circumvent  inadvertent  initiation  of  BIT  in 
flight.  Without  the  Interlock  closed,  BIT/preflight  test  cannot  be  initiated.  For  a production 
system,  the  interlock  function  would  be  controlled  by  using  landing  gear  ground  sensing 
switches  and/or  by  other  aircraft  configuration  sensing  fail-safe  logic. 

The  Initiate  switch  actuates  a discrete  through  the  interlock  switch  which  creates  a 
BIT  initiate  flag  in  the  computer.  In  response  to  the  BIT  initiate  flag,  the  executive  program 
jumps  to  the  BIT  software  routine  and  begins  to  automatically  sequence  through  147 
specific  hardware/software  test  steps.  These  tests  induce  failures,  check  for  proper  failure 
detection,  remove  failures  and  reset  monitors,  and  retest  for  normal  operation. 

The  three-digit  numeric  display  annunciates  the  current  test  in  progress.  Should  a test 
require  operator  action,  the  test  number  denoting  that  action  will  remain  annunciated  until 
the  action  is  taken.  Should  a test  fail,  the  appropriate  channel  no-go  light  will  be 
illuminated,  and  the  BIT  will  stop  with  the  failed  test  number  displayed. 

The  continue  test  button  is  used  to  acknowledge  specific  BIT  tests  calling  for  operator 
recognition  and  to  continuing  BIT  following  a failure  indication  once  the  failed  test  number 
has  been  recorded. 

The  WWCS  functions  checked  by  BIT  are: 

• SSCU  light-emitting  diode  display 

• Central  processor  arithmetic  fault  detection  and  interrupt 

• Memory  fault  detection  and  interrupt 

• Cross-channel  data  parity  monitor 
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• Parity  check  for  all  of  memory 


• All  majority  logic  voters  and  associated  monitors 

• Fail-operative  clock  switchover  circuitry 

• A/D  and  D/A  circuits 

• CP  oscillator  and  input/output  (I/O)  oscillator  frequencies 

The  computer’s  cross-channel  data  link  provides  the  means  to  reliably  compare  the 
success  of  each  BIT  test  step.  Each  computer  initiates  a given  test  stimulus,  obtains  test 
results,  and  trades  the  test  success  status  with  the  other  computers  via  the  cross-channel  data 
link.  If  a test  proves  unsuccessful,  all  three  computers  stop  processing  BIT,  and  identify  and 
output  the  failed  test  number.  The  computer,  which  is  able  to  locate  the  fault  illuminates  its 
no-go  indicator. 

4.4.3.2  BIT  Mechanization 

In  order  to  conduct  the  WWCS  integrity  checks  required,  as  a result  of  the  FMECA 
studies,  additional  hardware  elements  were  added  to  the  computer  subsystem.  These 
elements  (fig.  4-24)  allow  the  insertion  of  simulated  failed  signals  so  that  potential  latent 
failure  states  can  be  cleared.  Failure  inducing  hardware  was  added  to  the  following 
functional  circuits: 


Primary /secondary  oscillator 

Primary  oscillator  monitor  (to  test  clock  switchover  voter/monitor) 

CIU  clock  output  transmitters  (to  test  clock  MLV/monitors  in  CU’s  and  STRU) 
Iteration  reset  drivers  (to  test  iteration  reset  MLV/monitors  in  CIU’s  and  CU’s) 
Cross-channel  data  link  parity  generator 
Memory  parity  generator 


In  addition  to  these  failure  stimuli  points,  the  system  computational  reset  and  error 
reset  functions  were  modified  to  permit  their  activation  by  the  software  program.  This 
substantially  reduced  the  required  BIT/operator  interaction. 

To  prevent  an  inadvertent  inducement  of  failure  stimuli,  BIT  signals  are  controlled  by  a 
double  interlock.  First,  all  stimuli  signal  paths  pass  through  contacts  controlled  by  the 
interlock  switch.  The  stimuli  signals  are  all  discretes  originating  in  the  BIT  program, 
transmitted  serially  to  the  SSCU,  and  converted  to  discretes  routed  to  the  interlock  switch. 
The  second  interlock  is  the  BIT  initiate  switch.  This  switch  must  be  activated  to  enable  the 
BIT  discretes  and  to  initiate  the  processing  of  the  BIT  program.  However,  the  initiate  switch 
can  only  start  the  BIT  program  if  the  interlock  switch  is  closed. 
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The  BIT  control  commands  enter  the  computer  unit  through  a discrete  device 
controller  interface.  If  the  WWCS  processors  are  executing  a flight-control  (real  time) 
program,  the  BIT  initiate  flag  is  checked  by  the  WWCS  executive  just  after  the  I/O  timer 
interrupt.  Thus,  when  an  operator  initiates  BIT,  it  will  not  commence  until  the  end  of  the 
current  I/O  frame.  The  BIT  initiate  discrete  continues  to  be  interrogated  after  each 
interrupt,  while  BIT  is  being  executed  in  order  to  permit  exiting  from  BIT  at  the  discretion 
of  the  operator.  If  a failure  is  detected,  the  processors  jump  to  a wait  loop,  and  the 
appropriate  test  number  and  no-go  indicator  are  illuminated.  The  BIT  program  can  be 
continued  by  activating  the  continue  test  button.  This  button  is  also  used  to  continue  BIT 
after  a specified  operator  action  has  been  satisfied. 

4.4. 3. 3 BIT  Sequence 

The  following  is  a summary  of  the  WWCS  BIT  program  execution  sequence.  A 
te-t-by-test  detail  description  of  BIT  is  presented  in  appendix  D. 

The  program  starts  by  testing  the  system  status  and  control  panel  displays;  i.e., 
sequencing  the  illumination  of  the  display  elements  controlled  by  each  channel  (channel  A, 
B,  and  C).  The  program  waits  as  each  channel  drives  the  display  until  the  operator 
acknowledges  observing  the  display  by  pressing  the  continue  test  button.  This  is  followed  by 
internal  computer  unit  test  centered  around  the  CP’s  arithmetic  fault  interrupts  and 
memory  fault  (parity)  interrupt.  These  tests  check  the  central  processor/memory  monitors 
and  then  use  the  monitors  to  watch  over  the  related  hardware  elements  as  they  are  exercised 
by  the  processor. 

At  this  point,  the  triplex  operational  features  of  the  WWCS  begin  to  be  checked.  The 
computer’s  cross-channel  data-link  parity  monitors  are  tested  and  checked.  The  synchronous 
logic  interface  clock  voters  and  monitors  are  tested  followed  by  the  testing  of  the  STRU 
clock  voters  and  monitors.  These  circuits  are  systematically  faulted  to  exercise  the  first, 
second,  and  local  failure  detection/annunciation  capabilities.  Further,  the  MLV’s  involved 
with  these  circuits  are  completely  exercised  for  proper  input  and  internal  latent  fault 
screening  by  systematically  permuting  the  input  first  and  second  fault  states  for  all  input 
signal  combinations. 

The  next  series  of  tests  deal  with  checking  the  integrity  of  the  primary/secondary  I/O 
oscillators  and  associated  monitors  and  switchover  logic.  The  secondary  oscillator  is  faulted 
first,  and  a check  is  made  to  see  that  the  failure  is  detected  and  that  the  I/O  timer  interrupt 
continues.  Then,  the  fail-operative  clock  switchover  logic  is  tested.  The  clock  switchover 
voter  is  disabled,  and  the  primary  and  secondary  oscillators  signals  are  systematically 
faulted.  Proper  response  is  determined  by  checking  the  timer  interrupt  signal.  Then,  all 
combinations  of  oscillator  signal  failures  are  exercised  along  with  simulated  failures  of  the 
switchover  voter  inputs  to  clear  the  switchover  logic  of  latent  failure  potentialities. 

The  above  test  series  is  followed  by  a check  of  the  iteration  reset  voter/monitors 
located  in  the  computer  units  SLI.  Again,  proper  response  is  determined  by  checking  the 
timer  interrupt  iterative  operation.  (It  should  be  noted  that  a proper  monitor  response 
requires  that  only  specific  failures  be  detected,  wherein  all  monitors  are  checked  during  each 
significant  test  step.)  The  iteration  reset  voter/monitors  in  the  computer  interface  units  are 
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then  checked.  These  checks  are  made  by  systematically  controlling  the  SLI  operation 
(disable/enable)  one  channel  at  a time  in  permuted  combinations  and  observing  the  timer 
interrupt  signal  loss  and  resynchronization  ability. 

.The  final  triplex  tests  are  to  verify  the  integrity  of  the  computational  data  paths.  These 
are  achieved  by  loading  different  data  into  the  computer  units  output  buffers  and  checking 
for  the  proper  response  on  the  output  majority  logic  voter/monitors.  Again,  all 
combinations  are  permuted. 

The  final  test  series  are  simplex  in  nature.  An  assessment  is  made  of  the  analog 
interface  A/D  and  D/A  operation,  and  the  synchronous  clock  and  CP  clocks  are  compared. 
The  A/D  and  D/A  checks  are  accomplished  by  closing  a path  between  one  input  and  one 
output  of  the  analog  I/O  channels  and  by  checking  the  relative  signal  conversion  accuracies. 
The  clock  timing  checks  are  made  by  counting  the  CP  clock  pulses  between  I/O  timer 
interrupts. 

The  above  WWCS  tests  were  segmented  into  146  specific  test  steps.  The  total  test 
sequence  processing  time  is  approximately  18  sec,  discounting  the  operator  intervention 
time  at  the  beginning  during  the  display  tests. 

4.4.3 .4  BIT  Evaluation 

A number  of  hardware  elements  within  the  computing  subsystem  are  not  checked,  or 
at  least  not  exhaustively  checked  by  the  BIT  program;  e.g.,  the  power  supply  monitor,  the 
entire  instruction  set,  input  signal  conditioning  circuits,  and  all  sample  and  hold  output 
circuits.  Some  of  these  were  omitted  because  an  appropriate  FMECA  had  not  been 
accomplished.  The  input/output  functions  were  omitted  because  it  is  impractical  to  include 
such  functions  in  a subsystem  test;  their  testing  was  relegated  to  be  a part  of  the  overall 
flight-control  system  preflight  test. 

The  current  BIT  program  resides  within  two  pages  of  the  WWCS  core  memory  (1024 
words).  With  the  visual  inspection  of  the  SSCU  displays  made  and  the  appropriate  operator 
action  taken  to  continue  the  test  (required  3 times),  30  sec  represents  a nominal  execution 
time  for  the  BIT  program.  The  program,  however,  was  not  optimized  and  contains  several 
delay  processes,  which  were  added  to  overcome  hardware  anomalies  existing  during  the 
initial  stages  of  the  hardware/software  integration  checkout  effort.  The  operating  time  could 
be  reduced  by  approximately  6 sec  if  the  program  coding  was  recycled  (refined).  The  initial 
hardware  anomalies  were  corrected  before  the  equipment  was  delivered. 

The  BIT  program  played  a dual  role  during  the  development  of  the  WWCS  equipment. 
It  provided  an  engineering  exercise  to  gain  experience  in  defining  such  a function,  and  it  was 
used  to  systematically  check  the  system  operational  state  during  the  system 
hardware/software  integration  activity.  The  software  development  of  BIT  was  completely 
independent  of  the  actual  hardware  design;  i.e.,  it  was  prepared  from  the  system  functional 
specifications  and  not  drafted  from  a knowledge  of  the  actual  circuit  designs.  Therefore,  it 
became  instrumental  in  uncovering  differences  between  the  functional  design  intent  and  the 
actual  circuit  realization  of  the  specified  function.  The  differences  were  then  resolved  by 
reviewing  the  specifications  or  by  making  appropriate  corrections  to  the  hardware.  What  was 


important  about  this  process  was  that  design  inconsistencies  were  discovered  and 
understood  early  in  the  total  system  integration  period,  much  earlier  than  anticipated  if  BIT 
were  not  a subsystem  requirement  in  the  acceptance  test  of  the  hardware 


Another  important  aspect  of  BIT  has  been  its  ability  to  serve  as  a standard  between 
equipment  failures  and  application  software  programming  errors.  In  the  development  of  the 
operational  software,  BIT  could  be  quickly  used  to  determine  if  suspect  hardware  faults 
were  really  programmers  software  frustrations.  Its  use  and  value  can  be  easily  scoped  when 
the  alternative  is  to  setup  an  oscilloscope  or  other  pieces  of  laboratory  equipment  to  check 
the  hardware  against  gripes.  The  BIT  program,  as  implemented,  cannot  be  used  as  a good 
hardware  failure  diagnostic  routine  since  it  was  designed  as  a systems  go/no-go  checker 
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5.0  FLIGHT-CRITICAL  SYSTEM  PREFLIGHT  TEST 


The  automated  preflight  test  function  within  a flight-critical  system  is  comprised  of 
two  Darts  The  first  part  is  associated  with  the  self-test,  or  BIT  capability  internal  to  the 
primary  electronic  subsystem.  The  second  part  is  the  system  test  operations  that  are 
required  to  conduct  an  integrity  check  of  the  peripheral  hardware  elements  that  interface 
with  the  central  electronic  subsystem.  This  latter  part  assesses  the  health  of  he 
flight-control  hardware  associated  with  sensors,  servos,  flightcrew  controllers,  etc.  Since  the 
previous  sections  discussed  the  central  (flight-critical)  electronic  subsystem  preflight  test 
requirements,  this  section  deals  with  the  peripheral  hardware  test  (PHT)  requirements. 

The  PHT  study  included  programming  an  actual  test  for  the  laboratory  application 
flight-control  system,  HSAS.  This  program  was  implemented  using  the  WWCS  equipment 
and  became  an  annex  to  the  WWCS  BIT  program  to  form  a HSAS  preflight-test  test.  The 
following  is  a summary  of  the  PHT  implementation  and  evaluation. 

5.1  PERIPHERAL  HARDWARE  TEST  CONSIDERATIONS 

The  WWCS  preflight  test  laboratory  configuration  is  shown  in  figure  5-1.  The  primary 
elements  included  in  the  PHT  tests  were  the  WWCS  hardware,  simulated  pitch-rate  gyros,  a 
breadboard  mechanization  of  the  pitch-control  column  electrical-mechanical  interface,  and 
the  electric  command  servo-hydromechanical  subsystem.  The  preflight  test  laboratory  study 
objective  was  to  develop  a PHT  program  using  these  elements  to  better  understand  system 
test  and  test  executive  requirements. 

In  general,  the  PHT’s  were  developed  following  the  same  guidelines  used  in  the 
development  of  the  WWCS  BIT  (sec.  4.4.3. 1).  The  considerations  listed  below,  however, 
were  added  to  those  guidelines. 

• End-to-end  testing  (sensor  signal  to  actuator  command/response)  should  be  used 
wherever  possible.  It  was  assumed  BIT  validates  A/D  and  D/A  conversion 
accuracies;  therefore,  the  PHT  would  be  concerned  primarily  with  signal-path 
interface  continuity  checking. 

• Preflight-test  test  time  (BIT  and  PHT)  should  be  minimized. 

• Preflight  test  software  will  be  loaded  identical  in  all  three  computer  units.  It  is 
assumed  that  error-free  software  (i.e.,  a fully-validated  resident  program)  does  not 
fail;  therefore,  software  checks  are  not  to  be  a part  of  the  preflight-test  tests. 
(However,  tests  for  memory  failures  are  conducted  in  BIT.) 


5.2  PHT  ORGANIZATION 

Preliminary  timing  estimates  of  a PHT  based  on  the  application  model  extrapolated  to 
a three  axis  flight-critical  system  soon  indicated  that  a full-system  preflight  test  would 
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FIGURE  5-  1.-PREF LIGHT  TEST  LABORA  TORY  CONF/GURA  TION 


become  very  time  consuming  if  all  tests  are  conducted  in  series.  Therefore,  it  was  concluded 
that  an  acceptable  preflight  test  must  involve  executing  a substantial  number  of  tests  in 
parallel.  In  order  to  better  understand  the  series/parallel  testing  ramifications  of  an  all-axis 
flight-control  system,  the  system  functions,  shown  in  figure  5-2,  were  used  as  a reference  in 
developing  the  organizational  requirements  of  a PHT  program.  Both  sequential  (series)  and 
parallel  test  executions  are  necessary.  The  rationale  is  as  follows: 

• Many  functions  (items  of  hardware)  must  be  essentially  simultaneously  tested  in 
order  to  minimize  the  test  time. 

• Some  functions  (items  of  hardware)  must  be  tested  in  sequence  because: 

• They  must  time-share  flightcrew  (operator)  or  equipment. 

• Their  health  must  be  validated  before  they  are  used  to  validate  the  integrity 
of  other  functions. 

• They  must  be  sequenced  to  prevent  the  overloading  of  power  supplies  (e.g., 
hydraulic  power,  if  all  servos  are  simultaneously  driven  at  their  maximum 
rate). 

• Some  tests  will  have  precondition  requirements  that  must  be  satisfied  before  a 
test  can  begin.  This  is  illustrated  in  figure  5-2  where  manual  (operator)  action  is 
specified;  e.g.,  the  servo  testing  must  be  completed  before  manual  shutdown  is 
exercised. 

• Complete  testing  of  some  functions  may  require  sequential  execution  of  several 
different  tests. 

In  order  to  organize  a PHT  program  that  would  be  adaptive  to  satisfy  all  of  the  above 
requirements  and  guidelines,  the  following  definitions  and  program  structuring  was 
instituted. 

Test  Group 

A test  group  is  composed  on  one  or  more  tests  that  must  be  executed 
sequentially.  All  groups  could  be  executed  simultaneously  if  the  tests  do  not 
overload  the  computational  capability  of  the  CP.  If  a test  within  a group  fails.it 
will  not  necessarily  cause  other  tests  within  that  group  to  fail. 


Test 


A test  may  be  composed  of  one  or  more  tasks  that  must  be  conducted 
sequentially.  If  any  task  within  a test  fails,  the  test  is  failed.  All  Usts  are 
independent  from  each  other;  i.e.,  no  test  failure  will  cause  other  tests  to  fail, 
however,  the  failure  of  a test  may  exclude  the  valicfity  of  other  tests.  If  one  test 
shows  a display  to  be  inoperative,  all  other  tests  requ>ing  that  display  would  be 
invalid. 
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Task 


A task  is  the  smallest  item  of  work  that  can  be  programmed  as  a module  within  a 
test.  All  tasks,  except  for  the  initialization  task,  depend  on  the  success  of  the 
preceding  task  before  the  task  can  itself  be  successful. 

A PHT  executive  program  was  then  developed  to  administrate  the  peripheral  hardware 
test  group,  test,  and  task  programs  on  a computational  load  priority  basis. 

5.3  PHT  PROGRAM  EXECUTION 

Even  though  the  preflight  test  program  is  not  considered  a real-time  computation, 
reference  to  real  time  is  required  in  order  to  validate  the  operation  of  specific  system 
functions.  This  real-time  measurement  requirement  was  met  by  structuring  the  WWCS  PHT 
executive  to  complete  the  processing  of  a test  task  for  each  test  in  work  without  permitting 
a task  to  be  disrupted  by  the  I/O  timer  interrupt  signal.  Since  the  I/O  timer  interrupt  occurs 
at  precise  intervals  (6.144  ms),  it  was  used  as  the  primary  real-time  reference  within  the  PHT 
program. 

The  PHT  executive  was  further  structured  to  have  a test -in -progress  computational  load 
management  feature.  This  computational  load  management  capability  was  developed  in 
order  to  guarantee  the  consecutive  execution  of  test  tasks  of  tests  within  each  test  group, 
each  I/O  frame  time.  This  feature  was  devised  in  order  to  permit  a large  number  of  test 
groups  within  the  PHT  without  overloading  the  computational  capability  of  the  processor 
for  any  one  I/O  frame.  The  maximum  task  time  for  any  test  within  a group  was  to  be 
established  and  identified  with  that  test;  the  PHT  executive  would  control  the  number  of 
tests  executed  in  parallel,  such  that  the  sum  of  the  maximum  task  times  would  not  overrun 
the  available  I/O  frame  real  time.  Test  task  times  were  to  be  determined  during  the 
debugging  of  the  individual  tests.  With  this  computational  load  management  approach,  the 
processor,  in  executing  the  PHT  test  groups,  would  be  used  to  a reasonably  efficient 
working  capacity  without  requiring  careful  timing  changes  to  be  made  every  time  a test 
group  was  added  or  deleted. 

Pre flight-test  test  failure  for  a flight  dispatch-critical  system  could  result  in  a simple 
no-go  status  annunciation.  However,  some  degree  of  fault  isolation  is  required  before 
maintenance  action  can  be  taken.  Therefore,  the  PHT  program  was  designed  to  provide  test 
failure  identification  along  with  the  annunciation  of  a go/no-go  status.  Because  different 
tests  were  to  be  processed  in  parallel,  it  was  decided  that  a test  failure  should  not  stop  the 
testing  of  functions  unrelated  to  the  failed  test.  Thus,  it  was  concluded  that  the  PHT 
executive  would  store  test  failure  identification  information  for  recall  at  the  conclusion  of 
all  tests.  Provisions  were  also  included  in  the  PHT  executive  to  permit  rerunning  tests 
identified  as  failed  without  completely  recycling  through  all  other  tests  in  the  PHT  program. 

The  PHT  structure  of  the  application  model,  HSAS,  test  problem  involved  working  all 
of  the  requirements  discussed  ibove.  Figure  5-3  shows  a test  sequence  time  diagram  for  the 
three  test  groups  that  made  up  th<(  laboratory  problem.  The  computer  subsystem 
built-in-test,  WWCS  BIT,  is  executed  first,  followed  by  the  processing  of  the  PHT  tests. 
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FIGURE  5-3.-PREF LIGHT  TEST  LABORATORY  TEST  SEQUENCE 


Figure  5-4  is  a block  diagram  that  illustrates  how  the  PHT  executive,  test  groups,  tests,  and 
tasks  are  interrelated.  The  PHT  executive  handles  initialization,  timing,  test  group  selection, 
computation  load  management,  and  test  result  readout.  Each  test  group  and  each  test  have  a 
small  executive  to  direct  the  processing  of  their  respective  tests  and  test  tasks.  The  PHT 
program  processes  through  one  task  in  each  test-group-in-work  during  each  I/O  frame  time. 
After  the  completion  of  the  last  test  task,  a display  indicates  the  go/no-go  status  of  the  PHT 
tests.  The  operator  then  presses  the  continue  test  button,  (fig.  4-22)  and  the  program 
returns  to  the  beginning  of  BIT  (no  failures)  or  the  first  failed  test. 


5.4  PHT  LABORATORY  EVALUATION 

The  peripheral  hardware  test  covering  the  application  laboratory  HSAS  model  involved 
three  test  groups.  These  test  groups,  whose  time  relationships  are  depicted  in  figure  5-3,  are: 

Group  1- Pitch  control  column  and  servoannunciation/manual  control  tests 

Group  2- Electric  command  servo-hydromechanical  subsystem  tests 

Group  3— Pitch-rate  gyro  tests 

The  design  procedure  used  in  developing  the  PHT  program  for  these  test  groups  was  as 
follows: 

• Design  the  individual  hardware  functional  tests 

• Estimate  the  time  required  for  each  test  and  fit  the  tests  into  a sequence  time 
diagram  which  complies  with  all  precondition  requirements 

• Prepare  software  program  code  to  implement  the  tests 

The  individual  test  group  tests,  time  estimates,  and  program  memory  requirements  are 
discussed  in  the  following  subsections. 

5.4.1  Test  Group  Descriptions 

5.4.1 .1  Pitch  Control  Column  Tests 

Tile  control-column  interface  test  was  designed  to  check  the  control-column  redundant 
transducers  travel  limits,  tracking  accuracy,  and  dead  zone  (hysteresis)  levels.  The  flightcrew 
is  required  to  participate  in  this  test  group.  At  the  start  of  the  column  test,  the  test  program 
is  initialized,  and  the  crew  is  cued  to  exercise  the  control  column.  The  column  must  be 
moved  to  the  extremes  of  its  travel  and  be  given  some  short  quick  oscillatory  motions  about 
the  neutral  position.  A time  history  of  the  column  transducer  test  activity  is  shown  in 
figure  5-5. 

After  the  crew  exercises  the  colum.i,  the  continue  test  button  is  pressed.  The  computer 
checks  that  the  column  was  adequately  moved  to  its  travel  limits.  If  not,  the  test  will  be 
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failed.  Throughout  the  test,  the  computer  program  performs  two  types  of  cross-channel 
signal  comparisons  each  I/O  frame  time.  The  first  comparison  checks  that  the  transducer 
input  to  each  channel,  compared  across-channels,  remains  within  8%  of  the  transducers 
full-scale  travel.  The  second  comparison  checks  for  signal  nonlinearities  by  comparing  the 
transducer  signal  difference,  across-channels,  and  between  successive  I/O  frames.  If  the 
difference  exceeds  0.5%  of  full  scale,  the  test  would  fail  indicating  an  undesirable  level  of 
dead  zone,  a condition  that  could  arise  from  a sloppy  mechanical  installation  of  the 
transducer. 

5. 4. 1.2  Electric  Command  Servo  tests 

Servo-subsystem  tests  were  based  on  checking  the  following  hydromechanical 
characteristics  of  the  servopackage. 

• Operation  of  the  differential  pressure  (AP)  detent  mechanism 

• Servocentering  following  channel  depressurization 

• Force  authority  of  each  channel 

The  time  sequenced  test  tasks  for  the  EC  servotests,  as  illustrated  in  figure  5-6,  are 
described  below. 

Tasks  0 and  1 initialize  the  servo-subsystem  tests.  Task  2 checks  that  the  AP  detent  in 
channel  1 will  bypass  in  the  positive  direction  for  a hardover  command,  and  that  the 
hardover  does  not  disturb  the  redundant  servooutput  position  beyond  acceptable  limits. 

Task  3 checks  that  the  servo-subsystem  output  tracks  the  two  operative  channels  when 
one  channel  is  hardover.  Task  4 is  the  same  test  for  one  channel  depressurized  and  the 
servocentering  detent  engaged. 

Task  5 checks  that  the  AP  detent  in  channel  2 will  bypass  in  the  negative  direction,  and 
that  this  hardover  does  not  drive  the  subsystem  output.  Channel  2 is  then  depressurized  and 
task  6 checks  that  channel  3 cannot  overcome  the  two  centering  detents  and  drive  the 
subsystem  ouijw-'i 

These  test  tasks  are  executed  three  times  in  succession,  where  the  system  redundant 
channels,  A,  B,  and  C,  are  permuted  through  the  test  series  shown  in  figure  5-7  for  channels 
1 , 2,  and  3. 

This  series  of  tests  verify  that: 

• Each  AP  detent  will  bypass  in  both  the  negative  and  positive  direction 

• Each  combination  of  two  servos  has  a load  driving  capability  to  drive  the 
subsystem  output  with  the  other  channel  bypassed  or  depressurized 
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FIGURE  5-6.— ELECTRIC  COMMAND  SERVO  TESTS 


• Each  centering  detent  has  an  adequate  force  capability  to  assure  that  a second 
hardover  will  not  drive  the  subsystem  output 

• Each  combination  of  two  centering  detents  prevent  the  other  channel  from 
driving  the  subsystem  output 

It  was  assumed  that  servoload  equalization  (if  required)  and  subsystem  monitoring 
would  be  handled  by  software;  therefore,  these  functions  were  not  specifically  tested. 

5.4.1 .3  Rate  Gyro  Tests 

Rate  gyro  tests  were  developed  based  on  the  assumptions  that  the  gyros  could  be 
automatically  torqued,  and  that  they  would  respond  to  a step  disturbance  following  their 
specified  dynamic  response  characteristics.  The  gyros  were  simulated  on  an  analog  computer 
as  three  second-order  systems  having  a natural  frequency  of  18  H?  and  a damping  ratio  of 
between  0.5  and  0.8.  While  such  dynamic  characteristics  may  not  be  truly  representative  of 
the  response  of  a self-torquing  gyro,  the  tests  developed  using  the  above  assumptions 
permitted  the  evaluation  of  a preflight  test  program  structure. 

The  gyro-test  time  history  and  associated  test  tasks  are  illustrated  in  figure  5-7.  Task  0 
initializes  the  gyro  test.  Task  1 activates  the  torquing  coil  to  command  a l°/sec  positive 
gyro  output,  and  a cross-channel  comparison  is  made  to  see  that  the  three  gyros  remain 
within  their  specified  step  response  boundaries  over  1 6 I/O  frame  times.  During  the  last 
frame  time  of  task  1,  the  gyro  output  value  is  recorded  and  used  as  a steady-state  reference 
value  for  task  2.  This  value  must  be  within  ±10%  of  the  expected  l°/sec  command  value. 
Task  2 monitors  that  the  steady-state  output  remains  within  ±2%  of  the  steady-state 
reference  for  a period  of  50  I/O  frame  times. 

Tasks  3 and  4 repeat  tasks  1 and  2 by  driving  the  gyro  output  in  the  negative  direction. 
Task  5 essentially  repeats  task  1 with  the  gyro  torquing  coil  stimulus  removed  and  the  gyro 
output  returning  to  null  within  acceptable  null  offset  limits. 

5.4.2  PHT  Program  Structure 

The  peripheral  hardware  test  executive  was  set  up  to  execute  all  PHT  test  groups  and 
read  out  results.  Coding  was  included  to  reexecute  a failed  test  group  without  rerunning  the 
entire  PHT  program.  This  procedure  was  selected  so  that  improperly  set  preconditions,  such 
as  mode  switch  setting  or  improper  flightcrew  interaction,  could  be  corrected,  and  the  test 
reexecuted  with  a minimum  loss  of  time.  A flow  chart  of  the  PHT  executive  is  shown  in 
figure  5-8. 

The  PHT  program  design  required  that  the  program  executive  be  executing  when  the 
I/O  timer  interrupt  occurred.  In  the  event  the  timer  interrupt  occurred  during  the  execution 
of  a test  group  program,  the  PHT  program  would  stop  and  await  crew  action.  Such  a 
situation  could  arise  if  the  PHT  program  tried  to  execute  too  many  test  group  test  tasks 
within  one  I/O  frame,  or  excessive  time  was  used  in  recording  test  failure  states.  Should  this 
occur,  the  crew  could  depress  the  continue  test  button,  and  the  interrupted  test  group 
would  be  rerun.  If  a timer  interrupt  does  not  occur  before  the  last  scheduled  test  group  task 
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FIGURE  5-7.— RATE  GYRO  TESTS 
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is  completed  (normal  case),  the  PHT  executive  idles  in  a counting  routine  until  the  interrupt 
does  occur.  This  counting  routing  forms  the  base  for  establishing  how  much  available  time 
remains  during  an  I/O  frame  times  worth  of  PHT  computations. 

Following  a timer  interrupt,  the  PHT  executive  sequences  back  up  to  the  test  group 
subroutines.  Since  it  was  assumed  that  the  first  test  task  in  any  test  group  would  initialize 
* the  test  group  tests,  only  one  new  test  group  was  permitted  to  be  added  to  the  test  group 

series  during  any  one  I/O  frame.  Before  each  new  test  group  is  added,  its  maximum  use  of 
the  available  test  time  is  added  to  the  available  test  time  used  by  the  test  groups  in  process, 
and  the  test  group  would  be  skipped  if  its  time  with  the  others  would  overload  t»ie 
computational  load  during  an  I/O  frame.  When  a sufficient  time  margin  exists  because  other 
test  groups  have  been  completed,  the  new  test  group  begins. 

When  all  test  groups  have  been  completed,  the  test  results  are  readout.  If  a test  is 
identified  as  failed,  the  program  stops  and  awaits  crew  action  to  acknowledge  the  failure 
information.  After  all  failed  tests  have  been  recorded,  the  program  will  initiate,  with  an 
activation  of  the  continue  test  button,  a rerun  of  the  failed  tests. 

The  preflight  test  (BIT  and  PHT)  can  be  terminated  at  any  time  by  deactivating  the 
BIT  initiate  switch  on  the  system  status  and  control  panel. 

The  test  group  test  and  task  program  organization  is  shown  in  figure  5-9.  The  PHT 
executive  passes  program  control  to  the  test  group  program  using  a jump  to  subroutine 
operation.  The  test  group  program  has  a utility  executive  routine,  which  sequences  the  series 
of  tests  and  test  tasks  within  that  test  group.  The  general  structure  of  a test  series  of  tasks  is 
as  follows.  A task  is  entered  and  a test  is  made  to  determine  if  the  tusk  execution  will  be  the 
final  pass.  The  task  may  be  repeated  if  a preset  number  of  passes  is  required,  or  if  the 
program  is  awaiting  a cue  from  the  fiightcrew.  A task  operation  will  usually  be  to  control 
(initiate)  test  stimuli  or  to  record  a response  and  check  it  against  expected  response  data.  If 
the  task  detects  a default,  (a  test  has  failed),  the  program  jumps  to  a subroutine  that  will 
record  the  failure  state  information.  The  program  will  then  return  to  the  PHT  executive  and 
continue  into  the  next  test  group  test  task.  If  no  default  is  detected,  the  test  is  completed, 
and  the  program  returns  to  the  PHT  executive  to  continue.  The  last  test  task  includes  the 
test-finish-work  of  resetting  all  task  initial  states. 

I 

5.4.3  Computational  Load  Estimation 

I 

Test  time  requirements  are  an  important  factor  in  planning  a preflight  test  program  for 
a peripheral  hardware  test  having  many  test  groups.  The  total  test  time  depends  on  the 
computational  load  capability  of  the  computer;  i.e.,  the  number  of  test  groups  the  computer 
**  can  handle  during  a given  frame  time,  ’'art  of  the  PHT  development  effort  using  the  WWCS 

I was  to  determine  how  the  application  model  PHT  burdened  the  WWCS  I/O  frame  time.  The 

following  laboratory  tests  were  conducted  to  determine  WWCS  PHT  computational  load. 

!>  The  time  available  within  the  WWCS  I/O  frame  for  processing  PHT  test  groups  is  that 

remaining  following  the  execution  of  the  primary  executive  that  handles  the  I/O  timer 
interrupt,  and  the  execution  of  the  PHT  executive  that  initiates  the  first  PHT  test  task  and 
closes  out  the  last  test  task  before  the  next  I/O  interrupt  occurs.  This  available  test  time  was 
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FIGURE  5-9. -PHT  TEST  GROUP  TEST/TASK  ORGANIZATION 


determined  in  the  laboratory  by  processing  a dummy  test  group,  a simple  entry  and  exit, 
and  recording  a time  remaining  count  between  the  dummy  test  group  execution  and  the 
subsequent  I/O  timer  interrupt.  Each  test  group  of  u.e  laboratory  application  model  was 
then  executed  and  the  time  remaining  count  recorded.  This  was  followed  by  adding  one  test 
group  at  a time  and  by  recording  the  time  remaining  count  until  all  three  groups  were  being 
executed  simultaneously.  The  percent  of  available  PHT  test  time  used  during  the  above  tests 
are  listed  in  table  5-1 . 

The  data  in  table  5-1  show  that  67%  of  the  test  time  available  (for  the  worst  case  I/O 
frame  burden  during  the  total  test  time)  was  used  when  all  test  groups  were  being  executed 
together.  A summation  of  the  individual  test  group  worst-case  test  times,  however,  adds  up 
to  102%  of  the  test  time  available.  An  explanation  for  this  apparent  anomaly  is  illustrated 
by  figure  5-10,  where  the  I/O  frame  worst-case  computational  load  is  shown  to  be  a 
function  of  how  the  test  group  test  tasks  mesh  together  each  I/O  frame,  over  the  total  PHT 
test  period. 

In  conducting  the  above  tests,  two  test  groups  were  not  permitted  to  be  initiated 
during  the  same  I/O  frame.  This  was  the  only  special  constraint  imposed  for  combining  the 
test  groups,  since  some  initialization  tasks  were  prejudged  to  be  time  consuming  operations. 

From  this  laboratory  study,  it  was  concluded  that  if  a PHT  program  was  to  be 
executed  in  the  minimum  real  time,  it  would  be  necessary  to  fit  the  test  group  programs 
together  by  test  task  times  rather  than  by  total  test  group  or  test  times.  However,  care 
would  have  to  be  taken  to  preserve  test  task  continuity  for  real-time  tests  and  to  mesh  test 
tasks  such  that  the  time  available  within  one  I/O  frame  time,  WWCS,  would  not  be  overrun 
before  the  final  task  in  that  frame  was  completed.  This  conclusion  diminishes  the  usefulness 
of  the  test-in-progress  computational  load  management  feature  of  the  PHT  executive  once 
the  laboratory  development  work  reaches  the  final  test  sequencing  time-optimization  phase. 
The  feature  was,  however,  a useful  tool  during  the  initial  laboratory  work  of  combining  the 
various  test  groups  of  the  PHT  program. 

5.4.4  PHT  Memory  Utilization 

A breakdown  of  the  WWCS  memory  used  for  the  PHT  program  is  presented  in  table 
5-2.  The  basic  PHT  executive  required  353  words  of  code  with  an  additional  78  w^rds 
required  to  handle  the  test  group  test  and  task  executive  items.  This  gave  an  overall 
executive  overhead  of  431  words. 

The  memory  required  for  each  test  is  categorized  in  table  5-2  as  to  whether  it  is  unique 
test  code,  subroutines,  or  data  blocks.  The  right  hand  information  column  of  table  5-2 
contains  an  estimate  of  the  additional  words  of  memory  required  to  add  other  PHT  tests 
similar  to  those  implemented  in  the  laboratory.  For  instance,  the  column  tests  require  124 
words  of  memory.  To  add  an  additional  pilot  controller  transducer  interface  test,  the 
column  test  code  could  be  made  into  a subroutine  for  approximately  20  words  of  code;  a 
new  data  block  added  40  words.  The  new  test,  therefore,  would  only  require  about  60 
words  of  code  as  compared  to  the  initial  test  requiring  1 24  words.  A similar  approach  can  be 
taken  for  additional  EC  servotests  resulting  in  approximately  82  words  of  added  code  for 
one  additional  EC  servotest,  and  about  52  words  of  code  per  test  for  each  EC  servotest 
thereafter. 
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TABLE  5-1. -A  VAILABLE  PHT  TEST  TIME  USED  (I/O  FRAME  WORST  CASE) 
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FIGURE 5-10.-PHT COMPUTATIONAL  LOAD,  MESHING  ILLUSTRATION 
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5.4.5  PHT  Laboratory  Test  Conclusions 


The  laboratory  evaluation  of  a preflight  test  (WWCS  BIT  and  PHT  tests)  for  the  HSAS 
application  model  showed  that  the  approach  taken  can  result  in  a workable  test  sequence 
accomplished  in  a reasonable  time  period.  Coding  optimization  for  the  BIT  or  PHT 

nr!S!\T  T under;aken'  The  objective  of  the  laboratory  test  was  to  investigate 
P fight  test  schemes  and,  since  the  approach  taken  proved  satisfactory  without  cycling 
through  code  and  timing  optimization,  no  programming  refinement  was  attempted.  A strip 
chart  recording  of  the  preflight  test  PHT  tests  is  shown  in  figure  5-11. 

Per  the  SST  preflight  test  design  requirements,  the  application  model  preflight  test 
resulted  in  a go/no-go  indication.  Maintenance  diagnostic  requirements  were  not  investigated 

"l  5e  ptTat°ry  ey°T"d  thOSe  USed  in  the  PHT  executive  to  support  laboratory  checkout 
h h,e  pr0gram-  These  fau,t  ‘dentification/test-rerun  features,  however,  could  be  easily 
adapted  to  maintenance  testing  to  identify  a faulty  line  replaceable  unit. 

The  testing  concept  investigated  was  based  upon  an  operational  triplex  system  Test 
requirements  to  determine  the  operational  integrity  of  two  out  of  three  functional  success 
paths  of  a system  were  not  undertaken  and  are  viewed  as  being  an  easy  task  for  the  PHT 
program  and  a difficult  (involved)  task  for  the  WWCS  BIT  program.  Future  redundant 
system  prenight  test  development  efforts  should  include  formulating  a system  test  capable 
of  determining  the  system  s operational  state  even  though  a single  failure  exists. 

The  laboratory  preflight  test  study  demonstrated  the  versatility  of  a whole-word 
system  s capability  for  conducting  an  automated  system  test.  This  capability,  along  with  the 

rr0"  /h  M tH/  fal,s  within  that  squired  to  implement  most  (if 

the  ^-ntro,-,aw/red-dancy-anagement  functions  of  a flight-critical  system,  points  to 
e WCS  concept  as  being  the  most  powerful  subsystem  electronics  for  mechanizing  a 
redundant  flight-control  system.  This  position  is  based  on  the  use  of  a processor  having  a 
processing  speed  comparable  to  the  MCP-701  (80%  or  better).  8 
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APPENDIX  A 


ICPS  FMECA 


Contained  within  this  appendix  are  the  results  of  the  various  study  areas  associated 
with  failure  modes  analysis  for  the  ICPS.  By  partitioning  the  ICPS  into  major  functional 
blocks  as  discussed  in  section  4.3.2,  six  study  areas  were  identified.  Four  of  these 
(redundant  clock,  majority  logic  voter,  system  status  logic,  and  sensor  selection  and  failure 
detection)  fell  within  the  first  level  of  concern  since  they  are  involved  in  cross-channel  tie 
points.  The  two  remaining  areas  (input/output  circuitry  and  timing,  and  the  computer)  are 
second  level  areas  since  they  do  not  directly  interface  with  other  channels. 

In  presenting  the  failure  modes  data  for  each  of  these  six  sections,  a brief  description 
of  that  section’s  operation  will  be  given  prior  to  the  failure  modes  study.  These  sections  are 
discussed  in  a descending  priority  relative  to  the  system’s  sensitivity  to  their  failure  modes 
and  effects.  In  all  cases,  studies  were  only  done  as  a paper  analysis;  i.e.,  no  hardware  was 
actually  failed  (destructive  testing)  to  verify  study  results. 


A.I  REDUNDANT  CLOCK 

Throughout  the  mechanization  of  the  ICPS,  all  functions  and  hardware  are  triplicated 
with  the  exception  of  the  basic  oscillator  scheme.  Even  though  the  oscillator  exists  in  each 
CIU  (to  permit  interchannel  exchangeability),  the  harness  wiring  does  not  utilize  the 
channel  C oscillator  in  developing  the  redundant  clock  scheme.  The  clock  scheme  is  an 
active  standby  mechanization  utilizing  only  two  oscillators  to  develop  the  fail-operative 
clocking  structure.  This  type  of  redundancy  structure  is  always  suspect  relative  to  having  a 
single  failure  mode,  which  may  prevent  the  switchover  to  the  standby  elements  when  the 
active  elements  have  failed.  The  viability  of  this  design,  as  to  its  design  integrity  and  latent 
free  potential,  lies  strictly  within  the  realization  of  the  design  intent.  The  active  standby 
concept  by  itself  does  not  imply  that  a single  thread  failure  element  exists.  This  can  only  be 
ascertained  by  careful  study  of  the  actual  circuit  design. 

Figure  A-I  illustrates  the  operation  of  the  clock  system  of  the  ICP-723.  This  circuit  is 
repeated  in  each  channel  so  that  the  computing  subsystem  is  not  dependent  upon  a single 
clock  circuit.  Within  each  channel,  both  the  designated  primary  and  secondary  (as 
determined  by  harness  wiring)  are  checked  by  an  in-line  monitor.  The  outputs  from  the 
monitors  go  to  failure  status  logic  for  annunciation.  In  addition,  the  output  of  the  primary 
oscillator  monitor  is  used  to  initiate  a command  to  switch  to  the  secondary  oscillator.  To 
prevent  single  channel  (conmon  mode)  failures  in  the  monitor  and  switch-over  circuits,  the 
actual  switching  must  be  a majority  of  two  out  of  three  commands  to  switch.  This  is 
accomplished  with  the  use  of  a majority  logic  voter  (MLV)  discussed  in  section  A.2. 

This  switching  operation,  illustrated  within  figure  A-I,  is  implemented  through 
solid-state  logic  devices.  In  order  to  maintain  functional  independence  for  this  clock  system, 
the  basic  oscillator  signals  are  utilized  to  operate  the  sequential  logic  elements  within  the 
command  circuits.  To  ensure  that  sufficient  signal  is  available  to  operate  these  circuits,  the 
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primary  oscillator  is  passed  through  a long  delay  function  (equivalent  to  three  clocking 
cycles).  This  allows  the  monitor  time  to  achieve  a switchover  in  a transient-free  manner 
before  the  primary  oscillator  signal  is  lost  to  the  switch-over  logic. 

The  key  to  the  design  integrity  centers  about  the  ability  of  the  monitor  to  detect 
failures.  Thus,  the  failure  modes  study  starts  by  determining  if  there  are  any  postulated 
failure  states  that  the  monitor  could  not  detect.  If  there  are  none,  the  clock  logic  circuits 
may  not  need  to  be  analyzed. 

A.  1 . 1 Clock  FMECA  Approach 

The  design  of  the  primary  (secondary)  clock  monitors  shown  in  figure  A-l  verifies  that 
the  input  waveform  has  a negative  transition  every  500  ns.  This  task  is  accomplished  by 
toggling  a flip-flop  on  each  negative  transition  of  the  waveform,  where  the  output  of  the 
flip-flop,  \NDed  with  its  negated  value  and  delayed  by  500  ns,  represents  a signal  suitable 
to  drive  a failure  latch.  If  transitions  do  not  occur  at  the  500  ns  interval  (within  a tolerance 
50  ns),  this  ANDed  signal  makes  a state  change. 

The  FMECA  study  starts  by  first  determining  what  waveforms  can  satisfy  the 
operation  of  the  monitor.  By  drawing  the  time  history  waveshapes  through  the  monitor 
circuit,  one  can  easily  ascertain  that  there  are  several  frequencies  that  meet  the  monitor 
design  requirements.  These  frequencies  are  nominally  2MHz,  6MHz,  10MHz,  14MHz, 
18MHz,  or  any  other  frequency  higher  than  20MHz.  Therefore,  any  failure  in  the  oscillator 
countdown  and  waveshaping  circuit  that  would  result  in  any  of  these  signals  will  go 
undetected. 

A second  condition  that  needs  to  be  checked  is  one  in  which  the  waveshaping  circuits 
fail  to  a mode  where  it  is  still  providing  clocking  transitions  at  the  proper  intervals  but 
where  the  signal  waveform  will  not  be  satisfactory  for  driving  the  square  clock  signal 
generator  (fig.  A-l).  An  examination  of  this  circuit  shows  that  if  the  signal  into  :t  fails  to  a 
mode  where  it  is  zero  250  ns  before  each  negative  (clocking)  transition,  it  wiil  produce  a 
constant  output  (i.e.,  go  dead).  Furthermore,  if  such  a signal  fails  to  this  mode  without 
breaking  the  normal  500  ns  sequence  of  clocking  transitions,  then  the  monitor  will  not 
detect  the  shift  in  waveshape.  Thus,  the  monitor  cannot  request  a switch  to  the  secondary 
clock  driver,  and  it  will  be  a single  point  failure  to  all  channels  of  the  system.  In  summary, 
there  are  two  failure  modes  that  the  wavestiaping  circuits  must  be  checked  for;  transitions  to 
other  specified  frequencies  and  a waveshape  whose  negative  transition  is  always  preceded 
250  ns  by  a zero  value. 

A.  1.2  Clock  Countdown  and  Waveshaping  FMECA 

Figure  A-2  illustrates  the  clock  countdown  and  waveshaping  circuitry.  Since  it  contains 
memory  elements  (flip-flops),  failure  analyses  using  transition  matrices  were  utilized.  To 
keep  the  state  transition  diagram  reasonably  simple,  it  was  necessary  to  narrow  the  circuit  to 
be  analyzed  by  breaking  it  at  intermediate  points  where  interfaces  are  simple  and  easy  to 
understand.  An  example  of  such  a process  is  given  in  the  following  paragraph. 
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By  viewing  figure  A-2,  it  can  be  seen  that  flip-flop  1 (F/F  1)  simply  converts  the 
16-MHz  oscillator  square  wave  into  an  8-MHz  square  wave.  Therefore,  it  need  not  be 
included  in  the  state  transition  analysis.  (It  is  either  working  or  it  isn’t  working.)  The 
remaining  F/F’s  in  the  circuit  are  being  clocked  by  the  same  8-MHz  square  wave,  except  for 
the  output  stage,  F/F  5.  Since  F/F’s  2,  3,  and  4 are  being  driven  by  a negated  value  of  the 
clock,  F/F  5 essentially  is  made  to  lag  the  clocking  transitions  of  the  other  F/F’s.  (Clocking 
occurs  on  the  negative  transition  of  the  clock  signal.)  Therefore,  the  output  waveform  at 
F/F  5 will  be  the  waveform  Zq  (see  fig.  A-2)  delayed  by  62.5  ns  (1/2  of  an  8-MHz  cycle). 
Thus,  for  a state  transitional  analysis,  the  problem  is  reduce^  to  the  boundary  illustrated  in 
figure  A-2.  The  analysis  conducted  within  this  boundary  will  then  show  how  Zq  responds  to 
the  combination  of  signals  from  F/F  2,  (X)  and  hardware  failures  of  F/F  3,  F/F  4,  and  gates 
G1  through  G4.  This  boundary  has  reduced  the  circuit  to  one  in  which  there  are  three 
memory  elements  constituting  eight  possible  transition  states. 

As  a reference  base,  table  A-l  presents  the  operation  of  the  circuit  discussed  above 
when  there  are  no  failed  elements.  From  this  table  the  waveform  at  Zq  is  derived  which  has 
a cycle  of  1 /xsec.  During  each  cycle,  there  are  two  negative  transitions  500  ns  apart,  which 
satisfies  the  monitor.  Table  A-2  presents  operation  as  a function  of  1 1 probable  failure 
modes  within  this  circuit.  A review  of  this  table  shows  that  there  are  no  failures  that  can 
produce  any  of  the  off-design  nondetectable  frequencies.  However,  there  were  a number  of 
failures  that  produced  a suitable  signal  for  the  monitor  but  not  suitable  for  the  square  clock 
generator,  the  second  area  of  concern.  To  better  capture  the  significance  of  the  data  of  table 
A-2,  a summary  of  the  table  information  is  presented  below. 


Case  number 

Monitor  tripped 

Square  clock  signal  generator 

1 

Yes 

Stops 

2 

No  (conditional) 

Continues 

3 

Yes 

Stops  (conditional) 

4 

No  (conditional) 

Continues 

5 

No 

Stops 

6 

No 

Continues 

7 

No  (conditional) 

Continues 

8 

No 

Stops  (conditional) 

9 

Yes 

Stops 

10 

No  (conditional) 

Stops  (conditional) 

11 

No  (conditional) 

Stops 

As  can  be  noted,  several  of  the  failure  modes  are  conditional.  The  conditional 
detection  of  these  modes  depends  upon  where  the  circuit  is  in  the  transition  matrix  at  the 
time  of  the  failure.  Take  failure  case  4 for  example;  if  the  failure  occurs  while  the  circuit  is 
in  state  0,  3,  4,  or  7,  the  monitor  will  not  detect  a change  in  the  waveshape.  This  can  be 
deduced  by  viewing  the  waveshape  associated  with  failure  case  4 and  the  nonfailed 
waveshape  in  table  A-2i  For  instance,  if  the  failure  occurs  while  the  circuit  is  in  state  0,  the 
monitor  expects  to  see  another  negative  transition  in  375  ns  (three  states  later).  From 
failure  case  4,  a failure  occurring  during  state  0 forces  the  circuit  to  state  6,  then  to  state  3, 
then  to  state  7,  at  which  point  the  negative  transition  occurs  (375  ns  later).  On  the  other 
hand,  if  the  failure  had  occurred  while  the  circuit  was  in  state  2,  the  next  negative  transition 
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would  be  anticipated  one  state  later.  However,  this  failure  results  in  a negative  transition 
three  states  later,  thereby  breaking  the  normal  monitor  cycle,  and  thus  it  is  a detectable 
failure  situation. 

The  conditional  performance  of  the  square  clock  signal  generator  depends  upon  the 
tolerance  buildup  in  the  delay  line  within  that  circuit;  again  see  figure  A-l.  For  example, 
during  failure  case  8,  the  output  waveform  at  Zq  (see  table  A-2,  case  8)  will  be  sufficient  to 
produce  clocking  signals  if  the  delay  line  has  degraded  to  245  ns.  However,  the  clock  will 
stop  if  the  delay  line  has  degraded  to  255  ns.  In  any  case,  the  most  crucial  of  the  failures  is 
case  5 in  which  the  failure  is  undetected  by  the  monitor,  and  the  final  output  clock  signal 
stops. 

As  a consequence  of  the  above  analysis,  the  General  Electric  Company  proposed  an 
alternate  countdown  and  waveshaping  circuit.  This  circuit  is  illustrated  in  figure  A-3.  The 
intent  of  this  new  circuit  is  to  provide  the  same  normal  clocking  signal  but  without  the 
undesirable  failure  mode.  To  check  this,  the  analysis  was  again  repeated. 

Tables  A-3  and  A-4  contain  the  essential  results  of  the  repeated  analysis.  By  utilizing 
essentially  the  same  analysis  boundary,  as  illustrated  in  figure  A-3,  no  key  failure  could  be 
discovered.  The  only  failure  mode  discovered  that  went  undetected  was  for  case  1 . However, 
for  this  failure  mode,  the  clock  signal  is  still  produced.  Probable  detection  would  occur  at 
the  next  power-up  sequence.  At  that  time,  the  outputs  from  the  square  clock  signal 
generators  in  each  of  the  three  channels  would  not  become  synchronized  and  would  be 
one-half  cycle  out  of  phase  with  the  other  two  channels.  (The  designed  specialized 
waveshape  is  required  to  force  synchronization.) 

In  the  preceding  discussion,  the  study  emphasis  was  based  upon  a single  channel  failure 
affecting  multichannel  operation.  The  remaining  circuits  in  the  oscillator  monitor  and 
switchover  circuits  (fig.  A-l)  are  single  channel  oriented  failures.  (The  exception  being  the 
majority  logic  voter,  discussed  in  section  A.2).  A cursory  investigation  of  these  circuits 
found  no  failures  that  would  encumber  the  other  channels.  The  only  failures  found  were 
either  registered  by  downstream  voter  monitors  or  were  latent.  For  the  latter  cases,  preflight 
tests  for  cycling  the  majority  logic  voters  and  its  associated  monitors  were  developed  (see 
app.  D BIT). 


A.2  MAJORITY  LOGIC  VOTER  AND  ASSOCIATED  MONITOR 

Within  the  ICPS,  serial  data,  clock,  and  essential  elements  of  timing  and  control  are 
processei  through  a circuit,  entitled  an  MLV,  any  time  such  information  passes  between 
system  LRU.  The  system  intent  for  this  circuit  is  to  prevent  the  propagation  of  failures  from 
one  LRU  to  another.  At  these  MLV  points,  cross-channel  monitors  are  utilized  to  register 
failures  and  to  create  system  first  and  second  failure  status.  Essential  to  the  failure  analysis 
is  to  ascertain  failures  that  preclude  timely  failure  annunciation  so  that  simultaneous 
first/second  failure  situations  will  not  arise  because  of  unannunciated  failures. 


A.2.1  System  Description 


Figure  A-4  illustrates  the  MLV  circuit  and  its  associated  monitor.  As  can  be  seen,  the 
section  is  simply  implemented  by  the  use  of  four  NAND  gates  (Gl,  G2,  G3,  and  data  out 
[DO]).  This  implementation  processes  data  so  that  the  value  out  of  gate  DO  is  the  same 
value  as  the  majority  value  of  the  inputs.  The  monitor  portion  (the  remaining  10  elements) 

• interrogates  the  informational  data  string  upstream  of  the  voter  (cross-channel  signals). 

I 

Any  time  two  channels  do  not  contain  the  same  logic  levels  to  within  the  tolerance  of 
the  clocking  signal,  the  monitor  registers  that  fact  into  a latch.  The  latch  output(s)  is  then 
logically  combined  to  produce  the  first,  second,  and  local  failure  status  information.  Once  a 
latch  has  been  set,  it  can  only  be  cleared  by  manually  actuating  an  error  reset  command. 

A.2.2  FMECA  Approach 

Since  the  MLV  and  its  associated  monitor  represented  a relatively  few  number  of 
circuit  elements,  it  was  used  in  a comparison  study  between  hand  analysis  and  the 
computerized  aided  design  introduced  in  section  4.2.3.  When  the  potential  failure  cases  were 
postulated  and  tabulated,  the  number  was  so  great  that  the  hand  analysis  problem  was 
scaled  back  to  include  only  the  voter  circuits.  Dealing  with  the  entire  circuit  monitor  and 
voter,  were  relegated  to  the  simulator.  Furthermore,  for  the  hand  analysis,  it  was  assumed 
tnat  the  voter  was  processing  signals  that  required  the  output  to  switch  between  the  high 
and  low  state  and  that  the  monitor  would  detect  any  input  (upstream)  failures. 

Results  from  the  hand  analysis  (tabulations  not  included)  were  (see  fig.  A-4): 

• Output  failures  of  gate  DO  to  either  the  high  or  low  state  will  be  caught  by  the 
next  downstream  monitor. 

• Failures  in  the  output  of  gates  Gl , G2  or  G3  to  the  low  state  are  also  detected 
downstream  since  any  low  input  to  DO  prohibits  the  circuit  output  from  going 
low. 


• The  circuit  can  sustain  a dual  failure  such  that  if  the  output  from  any  two  of  the 
gates  Gl,  G2,  or  G3  are  high,  it  will  still  process  normal,  nonfailed,  data. 

If  this  latter  condition  is  not  tested,  latent  failures  may  buildup  without  being  detected 
and  cause  a loss  of  fail-operational  capability.  For  instance,  if  over  a period  of  time  the 
output  of  Gl  fails  to  a high  in  both  channels  A and  B,  all  channels  will  remain  operative  and 
there  is  no  indication  that  a failure  exists.  If  a short  to  ground  on  the  cable  containing 
channel  C data  were  then  to  occur,  total  system  operation  would  stop.  This  can  be 
illustrated  with  the  use  of  figure  A-4.  Since  the  output  of  G2  and  G3  in  all  channels 
becomes  high  with  a short  on  the  channel  C line,  and  since  Gl  is  stuck  high  in  channels  A 
and  B because  of  the  previous  latent  failures,  the  output  for  DO  becomes  and  remains  zero. 
This  zero  will  persist  and  continue  to  be  passed  on  from  A and  B and,  since  it  represents  a 
majority  of  two  out  of  three  at  the  next  MLV  mode,  the  entire  system  becomes  dormant. 
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A. 2.3  Computer  Aided  Analysis 

As  the  blocks  ot  digital  circuitry  under  analysis  grow,  the  analysis  becomes  too 
complex  to  be  treated  by  hand  in  a timely  manner.  To  such  ends,  computer  aided  analysis 
will  serve  as  a useful  tool.  To  gain  experience  with  computer  aided  analysis,  the  MLV  and  its 
monitor  were  evaluated  using  a logic  simulator  available  at  Boeing.  The  simulation  (ref.  4) 
required  logic  equations  of  the  circuit  to  be  analyzed,  a list  of  faults  to  be  inserted,  values  of 
input  signals  (or  sequence  of),  and  a list  of  the  outputs  to  be  monitored. 

The  equations  that  represent  the  circuit  in  figure  A-4  are  listed  in  figure  A-5.  The 
equations  are  modified  by  a compiler  for  the  simulator  to  convert  them  into  a suitable 
format  for  insertion  simulation.  For  example,  in  figure  A-5  the  NAND  gate  G1  was 
originally  defined  as 


G1  = (A  BUF  • B BUF)* 

From  this,  the  compiler  generates  the  fault  model  equation: 

G1  = ZG00000 1 • Z 1000001* 

ZG000001  = ZG000002  + ZI000002 
ZG000002  = (ZG000003  • ZG000004)* 

ZG000003  = A BUF  + ZI000003 
ZG000004  = B BUF  + ZI000004 

Note.  The  asterisk  (*)  is  used  to  denote  the  logical  complement. 

By  generating  the  fault  model  in  this  manner,  see  figure  A-6,  faults  can  be  inserted  into 
the  simulation.  With  all  ZI  inputs  to  the  gates  zero,  the  fault  model  is  functionally  identical 
to  the  original  NAND  gate.  But  by  applying  a one  to  each  of  the  ZI  inputs,  a failure  mode  is 
simulated.  That  is,  Z1000003  = 1 functionally  makes  the  A BUF  input  to  the  NAND  gate 
G1  act  as  if  it  is  stuck  at  one.  Each  of  the  input  equations  are  modified  in  this  manner. 
Figure  A-7  illustrates  how  each  device  in  the  test  cirvuit  is  made  into  a fault  model.  From 
this  figure  it  can  be  seen  that  for  a two-input  gate,  the  failure  modes  to  be  simulated  are: 


1-SI  = 

Input  1 stuck  at  one 

2-SI  = 

Input  2 stuck  at  one 

X-Sl  = 

Output  stuck  at  one 

X-S2  = 

Output  stuck  at  zero 

The  next  input  to  the  simulator  is  a list  of  faults  to  be  inserted.  For  this  circuit  there 
are  88  pertinent  nonredundant  failures.  These  are  tabulated  in  table  A-5.  Since  the  input  of 
a NAND  gate  stuck  at  zero  is  the  same  as  the  output  stuck  at  one,  both  failure  modes  were 
not  included.  Submission  of  the  input  data  sequence  and  outputs  to  be  monitored 
completes  the  simulator  data  package.  The  simulator  sequentially  institutes  each  failure  and 
applies  the  input  signal  sequence.  The  outputs  are  then  recorded  as  a function  of  each  test 
number.  These  outputs  can  then  be  compared  to  the  results  of  the  nonfailed  case.  Any 
difference  in  the  outputs  is  then  deemed  sufficient  as  a detectable  failure.  Section  A.2.4 

contains  the  sequence  and  results  of  these  simulation  runs;  a summary  of  this  section 
follows. 


’ 
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Table  A-6  contains  the  summary  of  detectable  failures  for  the  MLV  circuits  when 
processing  normal  data.  As  can  be  seen  from  this  table,  of  the  possible  voter  and  monitor 
failures,  70%  of  those  in  the  voter  and  65%  of  those  in  the  monitor  go  undetected  during 
the  processing  of  normal  data  (i.e.,  channel  A = channel  B - channel  C).  However,  if  it  were 
possible  to  manipulate  the  incoming  data  (to  the  voter)  such  that  a sequence  of  first  and 
second  failed  information  were  present,  the  number  of  undetected  failures  becomes  0%  for 
the  voter  and  10%  for  the  monitor,  see  table  A-7.  In  this  table  there  are  three  failure  modes 
that  can  be  classified  as  don’t  core.  These  are  K SAB  X-SO,  K SBC  X-SO,  and  K SCA  X-SO. 

These  points  in  the  circuit  are  normally  grounded  so  that  a failure  to  a zero  is  of  no 

consequence.  Three  other  nondetected  failures  (R  SAB  X-Sl , R SBC  X-Sl  and  R SCA  X-Sl ) 
are  detectable  when  interpreted  properly.  Each  of  these  failure  modes  will  prevent  the 
clearing  of  a failure  indication.  However,  this  failure  mode  would  be  detected  by  the  fact 
that  the  failure  indicator  lamp  would  not  be  extinguished  when  the  reset  button  is 
depressed.  The  seven  remaining  failure  modes  are  not  possible  to  detect  by  any  sequence  of 
input  conditions.  This  is  because  of  the  inherent  redundancy  in  the  functions  performed  by 
this  part  of  the  circuitry. 

The  redundancy  involved  can  be  illustrated  by  the  following  discussion,  and  the  aid  of 
figure  A4.  Take  the  case  for  any  failed  input  into  NAND  gate  G7.  The  normal  (no  data 

failures)  input  state  for  this  gate  is  all  ones.  This  gate  will  then  change  output  status 

(indicate  a data  failure)  for  any  single  input  being  zero.  For  instance,  if  channel  A fails,  both 
SAB*  and  SCA*  become  zeros.  Therefore,  if  any  one  of  these  inputs  were  stuck  at  one,  it 
would  not  affect  the  output  status  of  gate  G7.  This  similar  redundancy  design  is  what  makes 
the  first  and  second  input  into  LFAILN,  and  SCA*  and  SAB*  stuck  at  one  latent  failures. 
This  is  not  deemed  a deficiency  since  this  error  mode  could  be  removed  in  a production 
system  by  removal  of  one  of  the  redundant  links. 

A.2.4  Computer  Fault  Simulation  Runs 

This  section  contains  the  results  of  the  fault  simulation  runs  that  were  made  for  the 
MLV  and  its  failure  monitor.  For  each  of  the  failure  states  of  table  A-7,  the  fault  sequence 
of  table  A-8  was  utilized.  This  table  contains  the  test  runs  1 through  14  with  the  simulation 
run  procedures  used  as  shown  below. 

Runs  1 and  2-Normal  Data  Inputs 

The  register  level  program  was  written  to  control  the  logic  level  simulation  through  the 
following  sequence: 

1 . Insert  first  failure  mode 

2.  Apply  error  reset  pulse 

3.  Apply  input  data  (channels  A,  B,  and  C) 

4.  Wait  500  ns,  apply  negative  clock  transition 

5.  Wait  500  ns,  compare 
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6.  Increment  failure  mode  by  one 

7.  Repeat  items  2 through  6 

This  sequence  was  repeated  for  each  of  the  possible  failure  modes,  and  the  results  are 
presented  in  table  A-9. 

Runs  3 through  14-Combinations  of  First  and  Second  Fail  Data  Inputs 

The  register  level  program  was  written  to  control  the  logic  level  simulation  through  the 
following  sequence: 

1 . Insert  the  first  failure  mode 

2.  Apply  error  reset  pulse 

3.  Apply  first  fail  input  combination  (channels  A,  B,  and  C) 

4.  Wait  500  ns,  apply  negative  clock  transition 

5.  Wait  500  ns,  compare 

6.  Apply  second  fail  input  combination  (channels  A,  B,  and  C) 

7.  Wait  500  ns,  apply  negative  clock  transition 

8.  Wait  500  ns,  compare 

9.  Increment  failure  mode  by  one 

10.  Repeat  items  2 through  9 

This  sequence  was  repeated  for  each  of  the  possible  failure  modes  and  these  results  are 
presented  in  table  A-10. 


A.3  SYSTEM  STATUS  LOGIC 

The  full  implementation  of  system  status  functions,  as  well  as  system  control 
functions,  is  mission/vehicle  dependent  and  goes  beyond  the  bounds  of  the  FCD  task. 
However,  the  design  utilized  in  this  digital  subsystem  does  represent  the  typical  nature  of 
such  logic  and  does  provide  insight  into  associated  circuit  failure  modes.  Therefore,  the 
section  of  the  SSCU  panel  associated  with  first  and  second  failure  status  was  considered 
representative  of  the  system  problem. 

Within  section  A.2,  the  results  from  the  cross-channel  MLV  monitors  are  combined,  see 
figure  A-8.  The  latched  status  in  each  of  these  monitors  is  functionally  ORed  to  produce  an 
indication  of  failure  status.  The  annunciation  of  first,  second,  or  local  failure  is  driven  from 
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each  channel  within  the  system,  even  though  only  a single  channel  is  illustrated  in  figure 
A-8.  Local  failure  indication,  which  also  includes  in-line  monitoring  (power,  overflow, 
parity,  etc.)  via  computer  BIT,  are  not  truly  considered  part  of  the  system  failure  status.  In 
many  respects  they  represent  maintenance  information,  and  the  recombination  of  such 
failure  states  does  not  enter  into  the  system  functional  operation. 

The  failure  mode  tabulation  that  details  the  effects  associated  with  failures  of  the 
status  circuitry  is  shown  in  table  A-ll.  Only  first-failure  circuitry  is  included  since  the 
second-fail  circuitry  is  of  identical  design.  The  health  of  the  failure  status  logic  is  unknown 
until  it  is  exercised  to  annunciate  a failure.  Thus,  it  becomes  necessary  to  check  this 
circuitry  by  tripping  each  of  the  failure  monitors  for  both  first-  and  second-failure  cases  to 
assure  signal  path  continuity.  This  is  extremely  important  if  automatic  system 
disengagement  is  going  to  be  derived  from  the  status  logic. 


A.4  SENSOR  SIGNAL  SELECTION/FAILURE  DETECTION  (SSFD) 

All  variable  signals  coming  into  the  computing  subsystem  (ICPS)  pass  through  the  C1U 
SSFD  circuit.  Its  function  is  to  select  or  create  a single  signal  from  three  similar,  but  not 
necessarily  alike,  digital  signals.  This  selected  signal  is  then  passed  on  to  the  computer  unit 
and  enters  through  a majority  logic  voter.  Cross-channel  monitoring  on  the  SSFD  input 
signals  provide  failure  state  logic  to  mode  the  operation  of  the  signal  selection  algorithm. 

The  signal  selection  algorithm,  implemented  in  hardware,  selects  the  median  value  from 
a set  of  three  sensor  signals.  When  one  of  the  three  sensor  values  exceeds  a preset  difference 
from  the  other  two,  the  average  value  of  the  similar  two  signals  is  selected  as  the  SSFD 
output.  The  determination  of  the  out-of-tolerance  signal  is  based  upon  a set  of  parameters 
applied  to  the  differences  between  each  pair  of  the  signals  of  the  sensor  set.  These 
parameters  relate  to: 

• Lag  filter  time  constant 

• Allowable  magnitude  out  of  the  lag  filter 

• Allowable  time  the  lag  filter  output  is  above  the  allowable  magnitude 

• Washout  filter  time  constant 

• Allowable  magnitude  out  of  the  washout  filter 

• Allowable  time  the  washout  filter  output  is  above  the  allowable  magnitude 

This  selector  and  its  monitor  circuits  are  multiplexed  and  utilized  on  all  of  the 
incoming  sensor  signals  once  each  frame  time.  The  timing,  acquisition  of  data,  retrieval  of 
monitor  parameters,  and  registering  of  failure  codes  are  all  accomplished  by  harness  wiring. 
The  parameters  associated  with  the  failure  monitor,  however,  may  be  uniquely  tailored  to 
each  set  of  triplex  sensors  through  read -only -memory  programming. 
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Two  somewhat  independent  FMECA  studies  were  made  to  investigate  the  SSFD 
circuits.  Neither  study  resulted  in  an  in-depth  FMECA  treatment.  The  first  study  began  by 
developing  a complete  circuit  level  breakdown  of  the  SSFD  functions.  This  entailed 
constructing  1 2 detailed  drawings  where  each  drawing  covered  the  piece-part  makeup  of 
specific  subfunctions  within  the  SSFD  circuitry.  Figure  A-9  is  the  top  drawing  of  this  set  of 
drawings,  showing  the  breakdown  of  the  SSFD  subfunctions.  Figures  A- 10  and  A-l  1 are 
shown  to  illustrate  the  complexity  of  the  circuits  contained  within  each  subfunction.  The 
set  ol  drawmgs  was  then  used  to  analyze  the  failure  propagation/manifestation  for 
postulated  piece-part  failures.  This  approach  soon  became  unmanageable  because  of  the 
circuit  complexity  and  associated  time  and  manpower  demands  it  placed  on  the  FCD  task 


The  second  effort  utilized  the  same  drawings  but  was  an  analysis  of  the  SSFD 
functions  from  a top-down  functional  point  of  view.  In  this  approach,  failures  were 
postulated  on  a functional  level  and  a further  breakdown  of  the  function  only  took  place 
when  a failure  proved  to  compromise  the  SSFD  operation.  The  results  of  this  cursory 
analysis  are  contained  in  table  A-l  2.  The  results  show  that  68%  of  the  total  circuitry  may 
contain  latent  failures.  These  latent  failures  primarily  exist  because  the  SSFD  monitoring 
circuits  are  off-line  functions  under  no  failure  situations  (5%  associated  with  the  signal 
selection  mode  switching  and  63%  associated  with  the  monitor  functions). 

rirrnhr0,?t.thiS^Spny’  ^ C™dusions  could  be  draw"-  R«t,  since  the  signal  selection 
circuits  of  the  SSFD  process  data  in  a serial  fashion  and  all  paths  through  this  portion  are 

u i i zed  in  the  processing  of  non.  i!  data,  failures  within  these  circuits  would  be  detected  by 
the  downstream  MLV  monitor  (in  the  computer  unit).  Second,  all  the  monitor  related 
functions  are  off-line  and  can  develop  latent  failures,  which,  if  accumulated  in  two  or  more 
channels  could  lead  to  hazardous  situations  with  subsequent  failures  in  one  or  more  sensors. 

These  latter  circuits  must  be  exercised  periodically  in  order  to  establish  their  operational 
integrity. 


A.5  ANALOG  INPUT/OUTPUT  CIRCUITRY  AND  TIMING 

These  circuits  condition,  level  change,  and  transform  the  signals  from  outside  the 
subsystem  to  a form  suitable  for  manipulation  within  the  computing  subsystem.  In  a similar 
fashion,  they  transform  signals  within  the  computing  subsystem  to  a form  compatible  to  the 
external  subelements.  In  general,  the  signal  now  of  any  one  particular  input  (or  output) 
signal  has  its  own  dedicated  path  as  long  as  it  is  in  the  analog  signal  form.  Once  converted  to 
a digital  form,  the  signals  share  the  same  data  path  by  a multiplexing  process  that  stages 
(sequences)  signals  to  and  from  the  digital  processor  through  fixed  time  windows. 

A substantial  portion  of  these  circuits  lend  themselves  to  analysis  utilizing  analog 
techniques.  In  developing  the  FMECA  on  these  circuits,  a top  drawing  was  created  as  a 
guide,  figure  A-l 2.  Hardware  design  drawings  were  then  redrawn  to  functionally  represent 
the  subfunctions  identified  within  the  top  drawing.  Using  these  drawings,  a failure  modes 
table  was  deyeloped  (table  A- 13).  The  following  paragraphs  discuss  the  failure  mode  results 
presented  in  table  A-l  3 relative  to  each  subfunction  illustrated  in  figure  A-l  2. 
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A. 5.1  Analog  Input  Circuitry 

Both  dc  and  ac  sensor  signals  are  processed  within  the  circuit  boundary  shown  in  figure 
A-13.  Each  incoming  signal  is  passed  through  a prefilter,  which  is  utilized  to  condition  the 
signal  against  possible  line  noise  and/or  aliasing  errors  created  by  digital  sampling.  In  the 
case  of  the  dc  signal  conditioner,  a filter  with  a double  order  break  near  1 10  rad  is  used. 
This  double  breakpoint  was  selected  in  order  to  alleviate  aliasing  of  the  signal  for  the  6.144 
ms  I/O  frame  rate.  For  the  ac  prefilter,  the  breakpoints  were  set  to  keep  a 10  V rms  signal  at 
400  Hz  from  having  more  than  2.5  mV  ripple  (1/2  LSB  of  the  A/D  converter).  These  signals 
then  pass  through  an  analog  multiplexer  to  a single  A/D  converter.  The  A/D  converter,  upon 
command,  converts  the  analog  signal  to  its  equivalent  binary  value  represented  by  12  bits 
including  sign.  At  the  end  of  the  conversion,  the  digital  value  is  loaded  parallel  into  the 
lower  12  bits  of  the  A/D  register.  (The  upper  5 bits  of  the  16-bit  word  register  are  made 
identical.)  From  this  register,  the  data  is  shifted  LSB  first  to  the  signal  selection  circuitry  via 
the  serial  gating  circuits. 

Failure  modes  of  the  analog  processing  circuits,  demodulator  and  filters,  are 
predominantly  either  high  gain  or  passive.  The  ability  to  detect  the  passive  failures  will  be 
dependent  upon  the  sensor  tolerances  and  downstream  signal  selection  and  failure  detection 
levels.  The  sensitivity  to  these  detection  levels  will  be  discussed  later  in  this  section.  Failure 
effects  of  the  A/D  converter  used  in  the  1CPS  could  not  be  adequately  defined  because  a 
schematic  for  this  circuit  could  not  be  obtained.  Therefore,  in  order  to  develop  an 
appreciation  of  the  types  of  failure  modes  possible,  a converter  design  was  postulated  (fig. 
A-14).  The  analysis  results  presented  in  table  A-13  are  based  upon  this  figure.  Before  the 
failure  modes  of  this  circuit  are  presented,  a short  explanation  of  this  circuit  is  felt  to  be 
beneficial. 

The  input  amplifier  of  this  converter  takes  a ±10-V  analog  input  signal  and  converts  it 
to  a zero  to  -10-V  signal  so  that  a 0-V  input  signal  corresponds  to  a -5-V  level.  The  biased 
analog  signal  is  then  summed  with  the  current  from  a precision  ladder  network  into  a high 
gain  comparator.  These  ladder  network  currents  are  controlled  by  F/F’s  such  that  if  the  F/F 
output  is  set  high,  the  ladder  input  is  connected  to  a precision  voltage  source;  if  the  F/F 
output  is  low,  the  ladder  input  is  grounded.  The  analog  to  digital  converter  has  its  own  clock 
signal  generator  that  is  independent  of  the  CIU  clock  signals,  except  that  it  must  receive  a 
convert  command  to  start  the  conversion  process. 

Assuming  a standing  analog  signal  exists  at  the  analog  input,  a convert  command 
initializes  the  counter  or  shift  register  (see  fig.  A-14)  and  causes  a clear  signal  to  go  from  the 
timing  logic  through  the  OR  gate  to  all  F/F  timing  gates.  All  the  F/F  timing  gates  are 
opened  at  Tq  to  clear  all  the  F/F’s  to  zero.  The  counter/shift  register  then  starts  counting  or 
shifting,  and  the  timing  logic  opens  each  F/F  time  gate  (one  at  a time)  in  a sequence  starting 
with  the  most  significant  bit  (MSB)  and  progressing  to  the  least  significant  big  (LSB).  During 
the  open  gate  time  interval  for  each  F/F,  a set  pulse  is  utilized  to  trial  set  the  F/F.  If  setting 
the  F/F  makes  the  ladder  network  output  greater  than  the  biased  analog  value,  then  the 
comparator  causes  the  F/F  to  clear  again  before  its  time  gate  closes.  Proceeding  in  this 
successive  approximation  mode,  a 1 2-bit  word  is  created  to  represent  the  input  analog  value. 
The  resulting  12-bit  digital  output  is  biased  to  the  positive  half  of  the  binary  number  system 
so  the  maximum  positive  output  is  all  ones  and  the  maximum  negative  output  is  all  zeros. 
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ne  ™ tl^  Std  ^ 1S  C°nVerted  to  the  twos  implement  number  system  by 
negutmg  the  most  s.gmt.cant  bit  shown  as  MSB  in  figure  A-13.  The  12-bit  number  is  then 
parallel  loaded  into  a 16-bit  shift  A/D  register  with  the  sign  bit  of  the  12-bit  word  repeated 
in  the  five  most  significant  bit  positions  of  the  1 6-bit  word.  P 

Re‘erring  back  to  table  A-l  3,  one  can  see  that  the  bulk  of  the  failue  modes  is  reflected 
by  signal  degradation.  For  instance,  if  the  output  of  a F/F  in  the  A/D  converter  fails  high  or 

Lwd  pSTf  ;c  othr  F/F;s  to  set  so  they  are  trying  to  ^ 

ti  c faded  F/F.  If  the  analog  value  is  such  that  the  failed  F/F  is  in  the  correct  state  for  the 
present  conversion  then  no  error  will  be  introduced.  For  example,  if  the  MSB  (bit  12)  is 
fa  ed  into  the  high  state,  no  error  is  introduced  for  any  analog  signal  between  0 and  +10  V 
but  al.  negative  input  signals  would  be  set  to  zero.  Thus,  failing  the  MSB  in  a fixed  state 
(zero  or  one)  will  make  the  A/D  converter  behave  similar  to  a half-wave  rectifier  This  is 
dlustrated  m figure  A-.5  view  (a).  The  effects  of  failing  the  output  oTeUher  F/F  1 1 oMO 

hi'oh  ''tv  Sh°W,!- tl  !'gUre  A'l5<  T°  understand  the  effects,  consider  that  if  bit  10  is  failed 
high,  it  can  cause  bit  1 1 to  set  low  when  it  is  supposed  to  set  high.  If  both  bits  1 1 and  10  are 

supposed  to  be  low  but  bit  .0  is  failed  high,  then  all  lower  ofder  bits  wi,,  sit  low  to  try  to 
correct  the  error.  As  a comparison,  the  effects  of  failing  any  of  the  lower  three  bits  highlre 
shown  in  figure  A-l 6.  From  these  drawings  it  can  £ concluded  that  ,S2e  bit Sires 

r/V  reS°lutl0n  caPablllty  of  the  A/D  conversion,  and  if  the  bits  fail  high  they 
P ent  the  digital  output  from  having  a zero  or  null  value.  This  type  of  resolution  loss 

Tth  norma.0"/  T*  ^ Cha"nel-  1,16  caPabi,itV  to  dete^t  these  failures 

with  normal  data  depends  on  the  bit  significance  being  greater  than  the  downstream 

monitor  fa, lure  defection  level  and  signal  molion  being  great  enough  to  cause  the  signal  to 
jump  in  excess  of  the  monitor  threshold.  e 

To  better  visualize  the  significance  of  each  of  the  12  bits  of  the  A/D  converter  in 
erms  of  the  fractional  part  of  a full-scale  value,  refer  to  figure  A-l  7 If  a signal  has  a 

Zlr  m Zh  ring  °f  ±5%  °f  fUl1  Sca,e>  0n,y  fai,ures  in  the  *°P  four  bits  (1,.,  bits  9 
hi  1 Zh  , gilarantCed  aS  detectable.  The  significance  of  the  first  eight  bits  would 

be  ess  than  the  failure  detection  level  ( 1 0%  of  full  scale).  Thus  75%  of  the  bit  failures  under 
these  conditions  would  probably  be  latent  passive.  Such  failures  in  two  or  more  channels 

St  Zh  Sr"  U°IeSS  d°W0Stream  Signa'  Se“-  detection  guards 

Failures  associated  with  the  internal  timing  signals  might  have  the  effect  of  mixing  data 
from  previous  conversions  with  the  present  conversion.  This  results  in  an  unpredictable 
put  since  the  data  significance  of  the  previous  word  may  have  little  relationship  to  the 
c rrent  word  (i.e.,  the  A/D  is  time  shared  between  a maximum  possible  32  different  input 
signals)  so  one  cannot  make  the  assumption  that  there  is  a small  change  between  the 
previous  value  and  the  present  value  of  any  conversion. 

as  „art"oUMh°/  aClUa"y  °CCUrred  during  ",e  labora,or>'  '«*« 

as  part  of  the  FCD  studies.  The  most  common  failure  was  one  manifested  bv  a low 

frequency  wandering  offset.  Its  magnitude  generally  fell  within  the  first  five  bits.  Another 

failure  mode  was  one  in  which  the  converter  refused  to  respond  to  convert  commands-  a 

typically  passive  mode.  However,  since  twos  complement  data  were  being  extracted  (MSB 

being  complemented),  this  failure  was  manifested  with  full-scale  negative  output;  a situation 

easily  detected  by  the  sensor  monitoring  circuits. 


Failures  in  the  A/D  register  (fig.  A- 13)  are  similar  in  nature  to  those  described  for  the 
A/D  converter.  A failure  to  load  bits  into  the  register  would  normally  be  detected  only  if  it 
occurred  in  the  upper  four  or  five  most  significant  bits.  However,  failures  that  caused  the 
bits  to  shift  out  as  zeros  or  ones  would  have  the  effect  of  making  the  input  vs  output 
characteristics  look  like  a sawtooth.  Figure  A-18  illustrates  this  example  for  the  case  of 
failures  to  zero.  The  peak  of  the  sawtooth  will  depend  upon  the  significance  of  the  failed 
location.  A failure  in  a lower  order  bit  will  make  the  peak  of  the  sawtooth  very  low.  A 
failure  in  bit  position  12  will  make  th^  sawtooth  peak  at  full  amplitude  (fig.  A-18  view  [b] ). 
It  should  be  noted,  as  illustrated  in  figure  A-18,  view  (a),  that  a failure  in  a bit  position 
above  the  normal  12-bit  converter  will  produce  an  equivalent  signal  in  excess  of  the  nominal 
scaling  range. 


A.5.2  D.  Crete  Input  Circuitry 


These  circuits  (fig.  A-19)  provide  level  changing  of  the  incoming  discretes  (0  to  10  or 
28  V dc)  to  0 and  +5-V  logic  levels.  These  signals  then,  like  the  analog  signals  discussed 
above,  pass  to  a multiplexer.  The  multiplexer  output  is  transmitted  to  an  MLV  signal 
selector.  All  failures  of  the  input  discrete  circuits  result  in  a fixed  or  wrong  output  value. 
Therefore,  the  downstream  MLV  and  its  associated  monitor  will  prevent  error  propagation 
and  provide  failure  detection. 


A.5.3  Input  Signal  Serial  Gating 


This  circuit  (fig.  A-20)  multiplexes  all  incoming  signals  to  be  transmitted  to  circuitry. 
Manual  initialization  (system  computational  reset),  as  well  as  sensor  data,  is  sequenced  and 
placed  on  a serial  data  buss.  In  the  case  of  the  sensor  data,  a parity  bit  is  added  in  the  serial 
string  in  order  to  give  further  credibility  to  the  transmission  link.  This  parity  check 
essentially  clears  all  failures  within  this  circuit  with  the  exception  of  the  gate  through  which 
the  sensor  data  passes  (see  fig.  A-20).  Failures  of  this  element  force  data  to  be  either  all 
zeros  or  ones.  For  twos  complement  notation,  this  is  equivalent  to  a near  zero  value.  Parity 
will  not  assist  in  this  error  detection  because  the  calculation  of  the  parity  bit  is  downstream 
of  the  failure  point.  Detection  for  this  error  will  require  signals  to  be  above  their  associated 
monitor  threshold  of  the  sensor  selection  circuitry. 


A.5.4  Output  Buffer  and  Discrete  Circuitry 


Data  processed  by  the  digital  computer  reenters  the  analog  interface  unit  through  the 
bit  buffer,  see  figure  A-l  2.  This  buffer  serves  to  transform  the  serial  data  string  into  the  time 
reference  of  the  interface  unit.  From  this  buffer,  the  data  is  distributed  to  either  the  D/A 
interface  (to  be  discussed  in  the  next  section)  or  to  the  discrete  output  circuits  (fig.  A-21). 
Discrete  data,  which  arrives  throughout  the  frame  period,  are  shifted  and  stored  into  a 
receiving  register  one  bit  at  a time.  At  the  end  of  the  frame,  the  contents  of  the  entire 
register  are  simultaneously  transferred  into  holding  latches.  From  these  latches,  the  discretes 
are  further  buffered  and  level  converted  to  drive  peripherals. 


The  majority  logic  voter  upstream  of  the  bit  buffer  prevents  failure  propagation  of 
upstream  failures.  Voter  output  failures  or  the  bit  buffer  failing  high  or  low  will  cause  all 
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serial  data  to  output  as  ones  or  zeros.  This  will  cause  all  discrete  outputs  to  be  zero. 
Detection  of  these  failures  will  depend  upon  the  system  downstream  monitoring. 

The  discrete  shift  registers  could  fail  a bit  location  low  or  high  so  that  all  bits 
downstream  of  the  failure  location  would  shift  in  as  zeros  or  ones.  Since  there  are  two  shift 
registers  feeding  the  quad  latches,  (fig.  A-21 ),  a single  failure  could  cause  a failure  of  one  to 
eight  of  the  possible  1 6 outputs.  Loss  of  a clock  signal  to  either  shift  register  or  to  both  shift 
registers  could  cause  8 or  all  16  of  the  discrete  outputs  to  be  unchangeable  in  the  failed 
channel.  If  the  clock  signal  to  the  shift  registers  occur  at  the  wrong  time,  then  the  registers 
will  load  in  the  wrong  data.  These  failures  can  be  tested  by  verifying  that  the  eighth  bit  in 
each  of  the  two  eight-bit  shift  registers  can  be  changed  high  or  low.  In  general,  the  quad 
latch  can  fail  and  output  high  or  low  or  all  outputs  or  any  group  of  our  outputs  could  lose 
resetting  capability.  Detection  of  these  failures  will  again  depe  d on  the  downstream 
monitoring  (external  to  the  digital  equipment). 


A.5.5  Analog  Output  Circuitry 

Figure  A-22  illustrates  the  circuits  that  process  analog  output  data.  The  first  stage  of 
signal  processing  through  this  circuit  is  to  check  for  a potential  overflow  situation.  This  is 
required  because  only  the  lower  1 2-bits  of  the  1 6-bit  word  received  from  the  computer  is 
actually  passed  to  the  D/A  converter.  The  potential  overflow  is  checked  by  interrogating  the 
five  uppermost  bits  of  a register,  which  is  temporarily  holding  the  computer  output  value.  If 
they  are  not  the  same,  an  overflow  is  indicated  (fig.  A-22).  The  corrective  action  that  is  then 
instituted  is  to  convert  the  data  word  to  a full-scale  value  of  a polarity  indicated  by  the  sign 
(16th)  bit.  This  is  accomplished  by  loading  the  maximum  negative  value  into  the  temporary 
register  for  negative  overflow,  or  by  forcing  all  ones  into  the  data  string  as  it  is  passed  to  the 
D/A  register. 


Once  the  data  has  been  passed  to  the  D/A  register,  it  is  converted  to  its  analog 
equivalent.  The  conversion  process  was  accomplished  by  utilizing  each  bit  position  in  the 
D/A  register  as  voltage  weighted  information  into  an  operational  drive  amplifier.  The 
operational  amplifier  was  then  used  in  turn  to  drive  sample/hold  circuits.  These  circuits  are 
sequenced  one  at  a time  so  that  they  slew  to  the  current  value  on  the  drive  amplifier.  After  a 
sample/hold  has  acquired  its  output  values,  the  input  to  it  is  disabled  and  the  output  made 
to  retain  its  value.  The  D/A  is  then  allowed  to  develop  a different  signal,  which  is  then 
placed  on  the  next  sample/hold  circuit. 

Failure  detection  of  these  circuits  (tabulated  in  item  2.4  of  table  A-l  3)  depends  upon 
monitoring  in  the  next  downstream  subsystem.  In  sumnv-ry,  failures  in  the  overflow  «.• 

detection  circuits  cause  all  analog  outputs  of  the  failed  channel  to  ± hardover,  zero,  or  the 
inability  to  detect  overflows.  Failures  in  the  D/A  register  or  the  computer  data  buffer  that 
prevent  lower  ordered  bits  from  being  shifted  in  produce  a stairstep  output  (fig.  A-23).  The 
granularity  of  this  failure,  of  course,  depends  upon  the  location  of  the  bit  failure.  However, 
failures  in  the  D/A  register  such  that  the  register  properly  shifts  in  the  data.but  one  of  the 
output  bits  to  the  converter  is  failed  high  (or  low)  produce  an  output  waveshape  illustrated 
in  figure  A-24.  Such  a waveshape  would  undoubtedly  have  tremendous  impact  upon  any 
closed-loop  control  system  if  proper  design  at  the  servo-subsystem  does  not  block  such  a 
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signal.  Again,  the  effect  of  this  error  depends  upon  the  location  of  the  failed  bit.  For 
dramatization  of  the  effect,  figure  A-24  illustrates  failures  in  the  upper  bit  positions.  These 
failures  would  exist  in  all  analog  outputs  of  the  failed  channel  since  the  failure  is  in  the 
demultiplexing  data  string.  The  typical  failures  would  be  the  inability  to  sample,  or  to  hold. 

The  number  of  failures  that  fail  all  analog  output  paths  in  one  channel  could  be 
reduced  by  deleting  the  sample/hold  circuits  and  by  using  a separate  D/A  register,  converter, 
and  operational  amplifier  for  each  analog  output. 

A.5.6  Input/Output  Timing 

This  is  the  final  circuit  function  within  figure  A- 12  to  be  discussed.  It  is  within  this 
subtunction  (fig.  A-25)  that  all  the  control  of  the  hardware  elements  within  the  CIU  are 
developed.  The  essential  input  to  this  circuit  is  the  selected  square  clock  signal  from  the 
redundant  clock  circuitry.  (Iteration  reset  serves  as  an  initialization  signal  to  develop 
synchronization.)  The  squaie  clock  is  waveshaped  into  three  different  100  ns  pulses  as  is 
illustrated  in  figure  A-25.  These  pulses  drive  the  clocked  sequential  circuits  witnin  the  CIU. 
In  addition,  one  of  these  clock  signals  (bit  clock)  is  utilized  to  drive  the  bit  time  shift 
register.  This  shift  register  develops  the  basic  48  time  partitions  within  a timing  window 
identified  as  one  algorithm  time-one  complete  cycle  of  the  register  represents  one 
algorithm  time.  Every  cycle  of  the  bit  time  shift  register  is  utilized  to  increment  the  word 
counter  (and  advance  counter).  The  significance  of  these  counters  identifies  which  algorithm 
time  (0  to  127)  is  currently  being  processed.  The  advance  counter  and  the  word  counter 
essentially  perform  the  same  function;  the  only  difference  being  that  the  state  of  the 
advance  counter  is  always  two  algorithms  ahead.  The  purpose  for  this  is  to  preinitiate  the 
processing  of  incoming  sensor  data  so  that  there,  is  sufficient  time  to  process  data  through 
the  signal  selection  circuitry  before  it  is  required  within  the  computers.  The  amalgamation 
of  the  clock  signals,  bit  shift  register,  and  word  counters  (through  combinational  logic) 
produces  the  actual  device  control  lines.  These  control  lines  manage  the  various  pieces  of 
hardware  within  the  CIU  such  as  initiating  A/D  conversion,  shift  cortrol  to  various  registers, 
multiplexing  signals  on  to  data  busses,  etc.  The  sum  of  all  these  signals  results  in  the  fixed 
(hardwired)  executive  structure  for  the  CIU. 

Since  the  signals  (control  lines)  from  these  circuits  manipulate  so  many  hardware 
elements,  any  failure  in  them  that  produces  off  design  signals  would  have  massive  failure 
effects  throughout  the  CIU.  By  reviewing  item  3 in  table  A-13,  it  can  be  shown  that  failures 
in  any  of  the  clocking  signals  generally  prohibit  input  and  output  processes  because  clocking 
of  the  signal  transmission  devices  will  stop.  Thus,  clock  signals  failing  dead  (high  or  low)  are 
easily  detected  by  normal  monitoring.  Further  analysis  was  then  conducted  to  discover 
potential  failures  that  would  change  the  clock  signals  but  not  destroy  them.  These  failures 
center  about  the  two-input  NAND  gates  which  are  used  to  develop  strobe  and  clock  (CLK) 
signals.  For  instance,  if  the  input  into  the  strobe  NAND  gate  from  the  delay  line  fails  to  a 
high,  (refer  to  fig.  A-25),  then  the  strobe  signal  becomes  the  square  clock  signal.  The  leading 
edge  of  this  failed  strobe  signal  would  occur  at  the  same  time  as  the  leading  edge  of  the 
normal  strobe  signal,  but  the  trailing  edge  would  occur  400  ns  later  than  normal.  This 
increased  width  of  the  strobe  pulse  brings  its  high  time  equal  to  the  edge  of  the  leading  edge 
of  the  CLK  pulse.  Since  strobe  actuated  devices  are  dependent  on  both  the  leading  and 


trailing  edges  ot  the  strobe,  it  appears  that  this  failed  strobe  signal  would  cause  race 
problems  in  the  signal  processing.  The  net  results  cannot  be  easily  predicted. 

This  long  strobe  pulse  time  opens  up  the  possibility  of  the  strobe  devices  having 
incorrect  state  changes  caused  by  switching  noise,  synchronous  noise,  etc.  Many  of  the 
possible  consequences  are  ambiguous  or  unpredictable  without  laboratory  test.  In  general,  it 
was  concluded  that  all  failures  would  be  detected.  However,  laboratory  tests  would  have  to 
be  conducted  to  verify  such  a prediction  for  a production  system. 

Failures  in  the  bit  time  shift  register  and  word  counters  are  detectable  by  normal 
monitoring.  For  instance,  if  a bit  in  the  shift  register  fails  to  a high  or  to  a zero  in  a manner 
that  causes  it  to  shift  the  failure  into  the  downstream  bit  locations,  the  sequencing  of  the 
register  output  would  soon  end  in  a static  pattern.  After  being  reset  to  zero  at  iteration 
reset,  the  shift  register  would  again  reach  a steady-state  failure  condition  in  NF-1  clock 
pulses  where  NF  is  the  number  of  the  failed  bit  location.  Thus,  since  the  register  is  not 
cycling,  the  word  and  advance  counters  could  not  count  past  the  first  algorithm  time,  and 
the  input  and  output  timing  would  stop  in  the  failed  CIU.  Likewise,  failures  in  the  counter 
circuits  either  stop  the  count  sequence,  or  they  cause  the  wrong  count  sequence  to  occur. 
These  failures  in  turn  preclude  the  orderly  calculation  of  the  event  time  points,  which  are 
required  to  process  data. 


A.6  COMPUTER  UNIT 

All  of  the  previous  sections  of  this  appendix  have  dealt  essentially  with  hardwired  data 
handlers  and  formatters.  Within  the  computer  unit,  data  handling  is  both  hardware  and 
software;  i.e.,  data  handling  as  a function  of  2 programmed  series  of  instructions  that 
control  the  hardware  operational  states.  As  a consequence,  hardware  elements  may  exist 
that  fail  and  go  undetected  until  the  software  (instruction  set)  requires  that  they  function. 
The  study,  therefore,  was  to  identify  possible  latent  failure  states  within  the  computer  unit 
that  would  be  associated  with  the  processing  of  flight  control  functions. 

A.6.1  Processor  Description 


In  order  to  better  comprehend  the  construction  of  the  computer,  it  is  beneficial  to 
review  the  mathematical  model  of  the  incremental  control  processor  (ICP)  presented  in 
reference  1.  First,  the  processor  executes  mathematical  operations  utilizing  incremental 
arithmetic.  Second,  the  hardware  to  accomplish  this  task  is  mechanized  to  solve  a general 
incremental  equation,  the  rho  equation,  expressed  below : 

Pi  = Pi-i  (±)  Sq  AQ  (±)  Sp  AP  (±)  Vj  AW  (+)  Uj  AT 

I 

where 

Pj  = value  of  p nt  the  ith  iteration 
Ui  = Uj-l+AUi 

Vi  = Vj.,  + AVj 
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This  equation  is  then  further  modified  to  create  the  output  value,  AZ,  which  is  defined  as: 


I 


AZ  = Pj/Sz 


where 


and  AZ  is  constrained  to  one  of  the  values  0,  ±1 , ±2,  ±4,  ±8,  ±1 6,  ±32,  or  ±64. 

The  rho  equation  is  executed  128  times  per  processor  iteration.  The  output  of  one 
execution,  an  algorithm  time,  is  AZ.  This  output  can  be  used  in  succeeding  algorithms  as  an 
input  for  the  values  of  AQ,  AP,  AW,  AT,  AU,  AV,  or  as  a computer  output.  Computer 
programming  manipulates  the  rho  equation  by  specifying  where  in  the  data  memory  the 
values  of  the  A’s  are  to  be  found  (either  as  variables  or  constants);  the  sign  of  summations; 
the  values  of  constants  (S  , Sp,  Ug,  Vg,  pg);  and  the  source  of  S /Sp  as  being  either  from 
the  program  memory  or  from  the  data  input/output  (X/Y)  register.  By  selecting  various 
combinations  of  these  parameters,  a highly  sophisticated  filter  (second  order  over  second 
order)  can  be  implemented  using  two  algorithms. 

The  limitation  to  the  allowable  values  of  AZ  is  a hardware  consideration.  Even  though 
this  limitation  results  in  a degradation  of  equation  resolution  during  any  single  equation 
execution,  there  are  two  advantages  to  its  implementation.  First,  the  values  (0,  ±1,±2,±4, 
±8,  ±16,  ±32,  ±64)  can  be  decoded  into  a four-bit  word  by  using  2’s  complement  notation. 
This  feature  reduces  memory  volume  requirements.  Second,  by  having  these  input- 
parameters  to  the  rho  equation  expressed  as  a power-to-the-base-two,  multiplication  and 
division  of  parameters  can  be  executed  simply  by  shifting  operations.  This  reduces 
computation  time  and  hardware  elements  required  for  execution  of  the  rho  equation. 
Through  programming,  the  resolution  error  difference  between  the  selected  AZ  output  and 
the  ideal  calculated  value  can  be  stored  within  a rho  register  to  be  used  during  succeeding 
computations  of  the  same  algorithm.  This  results  in  a servoing  process  of  the  output  until 
there  exists  a zero  difference  between  output  value  and  the  true  calculated  value  after  a 
number  of  iterations. 

The  last  key  feature  of  the  incremental  control  processor  is  its  hardwired  executive. 
Since  the  execution  of  a control  law  function  is  developed  by  a series  of  algorithms,  the  ICP 
executive  relieves  the  programmer  of  the  task  of  linking  these  algorithms  together  by  always 
executing  a fixed  number  of  algorithms  per  iteration  (frame  time).  This  fixed  architecture 
allows  the  subsystem  to  be  mechanized  extensively  with  shift  (ring)  registers  as  a means  for 
storing  the  variables  (p,  U,  V,  X,  and  Y).  Since  the  executive  always  performs  128 
algorithms,  the  data  storage  locations  within  the  memory  and  the  ring  registers  can  be 
hardware  assigned  as  a function  of  the  time  within  the  frame  that  the  AZj  is  calculated. 

A.6.1.1  Hardware  Organization 

There  are  essentially  five  major  functional  blocks  that  comprise  the  1CPS  computer. 
These  functions  are  illustrated  in  figure  A-26.  The  functions  enclosed  within  boxes  are 


discussed  in  the  following  paragraphs.  The  othei  primary  elements  are  the  serial  MLV’s, 
previously  discussed  in  this  appendix.  The  voters  arc  utilized  as  functional  harriers  for 
isolating  iteration,  clock  and  data  informational  failures  among  LRU’s. 

As  shown  in  figure  A-26,  sensor  data  enter  from  the  interface  units  via  a majority  logic 
voter.  (The  interface  units  have  already  performed  a signal  selection  process.)  These  data  are 
then  changed  into  increment  form  by  the  incremental  I/O  function  illustrated  in  figure 
A-27.  The  increment  value  is  created  by  subtracting  a signal’s  past  value  from  the  current 
value.  The  difference  is  then  passed  through  an  increment  selector  whose  output  is  stored 
into  a random  access  memory  (RAM)  as  a AX.  During  the  next  frame  time,  the  AX 
increment  is  summed  with  previous  AX’s  of  the  same  signal.  This  sum  is  also  stored  in  a long 
shift  register  (identified  as  the  X/Y  register  in  the  figure)  as  X data.  (Servocommand  or 
output  data  are  stored  in  the  same  shift  register  as  Y data.)  Discrete  data  are  stored  directly 
into  RAM  without  the  incremental  selection  process  (the  interface  unit  havirg  already 
formatting  data  into  a four-bit  coded  number). 

Under  selective  programming,  the  current  value  of  a sensor’s  input  can  be  used  in  an 
algorithm’s  computation  instead  of  AX’s.  A special  16-bit  register  (illustrated  at  the  bottom 
of  fig.  A-27)  can  hold  one  full-sized  variable  until  it  can  be  utilized  within  the  control  law 
computation  at  some  later  algorithm.  A new  variable  can  be  stored  in  the  register  after  it  has 
been  utilized. 

Command  outputs  are  generated  by  summing  AY’s  into  the  X/Y  register.  These 
outputs  are  then  serially  shifted  to  the  interface  at  the  appropriate  timing  window.  It  should 
be  noted  that  X and  Y values  are  interleaved  within  the  same  shift  register.  During  the 
algorithms  times  when  data  are  not  sent  from  the  interface  unit  to  the  computer  unit,  the  X 
portion  of  the  register  may  be  treated  like  any  other  accumulator  within  the  rho  equation. 
Likewise  for  servocommand  outputs,  the  Y register  is  also  available  during  nonassigned 
(hardwired)  algorithm  times. 

The  outputs  from  the  increment  selector  in  the  I/O  section  are  stored  in  a random 
access  memory  within  the  increment  storage  section  illustrated  in  figure  A-28.  The  storage 
addresses  for  these  data  (both  AX  and  AZ)  are  determined  by  the  hardware  (word  time 
counter)  as  a function  of  time  during  each  frame.  These  values  are  then  retrieved  (to  be  used 
during  computation)  as  a function  of  software  programming,  illustrated  in  the  bottom  half 
of  figure  A-28. 

The  read  only  memories,  illustrated  in  the  top  half  of  figure  A-28,  store  the  program 
instructions  and  constants.  These  memories  contain  the  addresses  for  the  RAM  of  the  AZ 
values  desired  in  the  rho  equation,  as  well  as  all  the  parameters  for  controlling  the  arithmetic 
section.  These  latter  values  are  represented  as  initial  conditions  (Uq,  Vq),  gams  (Sp,  Sq  and 
any  A’s  that  are  to  be  constants),  rho  equation  moding  (signs  of  summations  and  selection 
of  shift  register  outputs),  and  branching  data.  The  addressing  and  moding  data  are  utilized  in 
a parallel  fashion,  while  the  initial  condition  values  and  Sp/Sq  values  are  sent  serially. 

Addressing  for  the  program  memory  is  controlled  in  the  timing  section  illustrated  in 
figure  A-29.  This  address  is  broken  into  two  parts.  The  first  address  represents  the  major 
address  for  the  ROM.  This  major  address  refers  to  the  first  location  of  a 12-word  block  of 


memory  in  which  all  the  parameters  per  algorithm  are  stored  (192  bits).  Each  individual 
word  within  this  block  is  retrieved  by  a minor  address,  an  address  formulated  by  a counter 
that  updates  once  every  3 ^sec.  Under  normal  situations,  addresses  for  instructions  are 
sequential.  These  addresses  are  created  by  incrementing  the  major  address  as  it  shifts  around 
a ring  register  (fig.  A-29).  During  a branching  instruction,  a new  address  is  inserted  into  this 
ring  if  the  branch  test  conditions  are  met.  When  a branch  has  been  executed,  selective 
registers  are  automatically  reset.  Branching  is  facilitated  by  comparing  the  current  next 
major  address  with  the  major  address  that  was  used  in  the  previous  frame  during  the  same 
time  period  (a  data  value  that  had  been  stored  in  the  rho  register). 

The  remaining  timing  and  control  logic,  illustrated  in  figure  A-29  (bit  shift  register, 
word  counter,  and  combinational  logic),  is  similar  in  design  to  that  used  in  the  interface 
unit.  Since  timing  and  control  logic  is  discussed  in  section  A.5.6,  it  will  not  be  repeated 
here. 


The  remaining  functional  element  in  figure  A-26  is  the  arithmetic  unit,  illustrated  in 
more  detail  in  figure  A-30.  Within  this  section,  the  various  variables  are  combined  (products 
as  well  as  sums)  to  make  up  the  rho  equation.  The  equation  is  so  mechanized  that  as  each 
input  variable  arrives,  it  is  used  in  creating  the  partial  sums.  The  mode  control  bits  utilized 
within  the  expression  are  latched  so  that  they  persist  throughout  the  computation.  These 
bits  are  used  to  close  switches,  illustrated  in  figure  A-30,  and  to  complete  the  various  data 
paths.  (Note;  control  bits  that  can  change  the  sign  significance  of  incoming  data  were 
omitted  from  the  figure  for  clarity  purposes.) 

A.6.1.2  Haidware  Monitors 

There  are  several  monitors  contained  within  the  computer  that  check  the  health  of  all 
memory  related  devices.  Checks  are  made  on  the  program  ROM  (instructions),  data  RAM 
(results  ot  computations),  and  on  the  major  shift  registers  (U/V,  X/Y,  and  rho  registers). 
Figure  A-31  illustrates  the  parity  checker  used  for  the  ROM.  This  circuit  is  designed  to 
check  that  the  sum  total  of  the  192  bits,  which  comprise  an  algorithm  instruction,  is  odd. 
This  is  done  by  comparing  the  running  total  of  the  parallel  ROM  words  to  the  serial  ROM 
words  once  each  algorithm.  Thus,  each  bit  of  the  12-word  instruction  set  is  checked  once 
each  iteration.  The  only  exceptions  are  the  instructions  that  reside  in  branch  loops,  which 
are  not  normally  executed.  It  should  be  noted  that  all  of  the  serial  data  for  algorithm  (n)  are 
not  completely  read  out  of  ROM  before  some  of  the  parallel  data  for  algorithm  (n+1)  are 
being  fetched.  To  account  for  this  fact,  the  bit  sum  significance  from  the  parallel  word 
toggle  is  double  buffered  (not  illustrated  in  fig.  A-3 1 ) so  that  the  proper  sum  is  available  to 
compare  with  the  serial  data. 

The  RAM  is  checked  by  the  use  of  data  comparison  as  illustrated  in  figure  A-32.  Any 
time  data  are  stored  into  the  RAM,  the  information  remains  on  the  write  buss  until  the  data 
can  propagate  out  onto  the  read  buss.  If  any  of  these  bits  disagree , an  error  is  flagged.  This 
ensures  that  proper  data  are  stored  within  the  RAM  at  the  time  it  is  loaded. 

Data  in  the  major  shift  registers  are  parity  checked  by  the  scheme  illustrated  in  figure 
A-33.  During  each  algorithm  time,  a running  total  on  the  number  of  bits  going  into  the  U/V, 


X/Y,  and  rho  registers  is  maintained.  At  the  end  of  each  algorithm  time,  a parity  bit  is 
generated  such  that  the  sum  of  all  of  these  bits  is  odd.  This  is  then  stored  into  the  rho 
register  along  with  the  address  bits  for  the  branch  test.  In  a similar  fashion,  the  data  are 
brought  from  these  registers  and  parity  checked.  This  check  assists  in  ensuring  that  data 

have  not  been  improperly  shifted  through  the  registers  during  an  iteration. 

Arithmetic  overflow  is  the  remaining  type  of  monitoring  function  that  is  illustrated  in 
figure  A-34.  This  monitor  assists  in  detecting  programming  errors  as  well  as  registering  some 
hardware  failures.  Not  all  of  the  summations  within  the  rho  equation  are  monitored,  only 
those  illustrated  in  figure  A-34.  The  other  summations  (like  UAT  + SpAP)  do  not  require 
monitoring  because  the  resulting  word  size  is  increased  to  accommodate  any  possible 
arithmetic  overflow.  In  the  same  fashion,  multiplication  (integer  in  this  machine)  is  not 
monitored  because  a larger  word  is  generated. 

The  remaining  monitoring  functions  (not  illustrated)  are  for  power  supplies,  clock 
signals  (after  waveshaping),  and  the  cross  channel  data  entering  via  the  MLV’s.  The  outputs 
from  all  of  these  monitors  are  combined  to  produce  local  and  first  failure  status. 

A.6.2  Processor  FMECA 

A failure  analysis  of  the  computer  3t  the  component  level  represents  a highly  difficult 
task  because  of  the  complexity  of  the  circuits  involved.  A functional  failure  analysis  was 
therefore  conducted  to  determine  if  by  having  a program  loaded  (HSAS)  would  the 
computer  be  self-monitored?  An  affirmative  answer  to  this  question  would  depend  on  the 
monitoring  system’s  ability  to  register  failures.  Thus,  the  analysis  for  latent  failures  was 
conducted  by  postulating  failures  in  the  computer  hardware  and  determining  whether  the 
designed  functions  of  the  built-in-test  equipment  would  register  them  through  the 
processing  of  normal  data  and  thereby  validate  the  operational  capability  of  the  computer 
processor.  For  this  analysis  it  was  assumed  that  the  monitoring  system  was  operational. 
Further,  the  results  ot  the  analysis  assume  a downstream  voter/monitor  to  prevent  the 
propagation  of  failures  from  the  computer  and  to  register  failures  of  the  computer.  Table 
A- 14  contains  the  results  of  the  analysis.  Pertinent  data  from  this  table  are  presented  below. 

A.6.2. 1 Incremental  Input/Output 

Within  this  section  there  are  several  latent  failure  possibilities  associated  with  the 
whole-word  input  buffer.  Because  the  input  buffer  was  not  used  in  programming  the  HSAS 
control  laws,  its  associated  failures  were  classified  as  don’t  care  failures.  If  the  register  had 
been  utilized,  the  latent  failures  would  have  essentially  disappeared  because  any  error  to  the 
input  signal  from  the  interface  would  create  an  output  command  different  from  the  other 
two  channels.  Depending  upon  the  nature  of  the  failure,  this  would  be  detected  either  by 
the  output  monitor  or  by  the  overflow  monitor. 

The  ability  of  the  increment  selector  to  select  all  significant  values  may  be  of  some 
concern.  However,  any  execution  of  more  than  1.5%  of  the  full  scale  of  any  sensor  d uring 
any  frame  time  will  test  this  function.  This  error,  if  it  was  present,  would  then  propagate 
through  the  computation  until  caught  by  the  output  monitor.  Therefore,  normal  signal 
excitation  should  clear  this  potential  failure  mode. 


The  only  other  remaining  potential  latent  failures  within  the  incremental  I/O  are  those 
associated  with  initial  conditions.  These  failures  can  prevent  the  insertion  of  proper  starting 
values  during  the  actuation  of  computational  reset.  They  become  a latent  failure  condition 
when  they  occur  while  the  computers  are  in  the  compute  mode.  However,  when 
compuiational  reset  is  again  actuated,  these  failures  will  be  manifested  by  the  output 
monitor. 

A.6.2.2  Program  Memory 

This  area  contains  only  one  latent  failure  possibility  that  is  associated  with  the 
integrity  of  the  control  bits  of  algorithms  which  are  not  in  the  mainstream  of  a 
computational  cycle  (instructions  in  a branch  loop).  The  potential  failure  is  whether  the 
desired  instruction  bits  are  present  in  their  assigned  storage  locations.  Such  failures  can  go 
undetected  until  that  portion  of  the  memory  is  exercised  since  some  portion  of  each  ROM 
chip  are  utilized  during  each  iteration,  their  input/output  buss  structure,  address  decoding, 
and  power  status  are  checked  by  normal  operation.  All  other  element  malfunctions  within 
the  memory  circuit  result  in  active  failure  indications  becuase  of  the  multiplexed  serial 
architecture  of  the  design. 

The  ROM  parity  checker  is  the  key  to  memory  fault  detection.  Each  bit  in  a 
semiconductor  memory  occupies  such  a small  area  on  the  chip  that  faults  due  to  heat, 
semiconductor  imperfections,  or  thin  oxide  layers  will  generally  encompass  more  than  one 
bit.  There  are  also  circuit  dependent  failures,  which  can  affect  several  bits.  Often,  several 
bits  are  electrically  attached  to  the  same  metallization  strip,  so  that  a single  short  or  open 
anywhere  on  this  strip  will  cause  all  attached  bits  to  fail.  With  this  background, 
semiconductor  memory  designs  and  parity  checking  structures  have  been  developed  that  will 
provide  a very  high  probability  of  failure  detection.  The  following  discussion  presents  an 
overview  of  the  associated  failure  detection  success. 

For  the^case  of  a one-bit  failure  in  a memory  word,  a parity  check  will  always  detect 
the  error.  (It  is  assumed  that  if  a zero  or  one  bit  fails  to  zero  or  one,  there  is  no  change  to 
the  data  significance;  therefore,  this  represents  a don’t  care  fault.)  By  looking  at  the  case 
involving  two  failed  bits  in  a single  memory  word  (fig.  A-35),  it  is  possible  to  derive  the 
generalized  expression  for  the  probability  of  detecting  a failure  as: 


P (don’t  care  failure/x  bits  fail)  = 1/2X 

P (detectable  failure/x  bits  fail)  = 1 /2 

P (undetectable  failure/x  bits  fail)  = 1/2-1  /2X 

P (detecting  the  faulf  or  don’t  = P (detectable  failure)  + P (don’t  care) 
care  fault/x  bits  fail)  1/2  + 1/2X 

where  x equals  the  number  of  failed  bits/word. 
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Thus,  a design  using  a single  parity  bit  to  check  parity  on  a single  word  can  offer  little 
more  than  50*^  error  detectability  on  a single  word.  But,  since  several  memory  words  reside 
within  the  same  ROM  device,  the  probability  of  detecting  a ROM  error  within  one  frame 
time  can  be  expressed  as: 

P (detecting  memory  fault)  = 1 - [P  (undetectable  failure)] f 

where  f equals  the  number  of  words  tested. 

Now,  if  x equals  17,  the  probability  of  detecting  the  failure  is: 

P (detecting  the  fault  in  any  single  word)  > 1 12 

And,  if  f equals  128  (the  times  a ROM  device  is  accessed/frame),  the  probability  of 
detecting  a memory  fault  becomes: 

P (detecting  memory  failure)  = 1 - 2.9  x 10'^ 
which  is  a very  good  probability. 

Therefore,  from  this  representative  analysis,  the  ROM  parity  checker  is  adequate  in  catching 
failures  associated  with  semiconductor  memories  dropping  or  adding  of  bits. 

A.6.2.3  Increment  Storage 

This  section  contains  one  potential  failure  mode  that  is  somewhat  self-correcting  and 
therefore  may  go  undetected.  This  is  associated  with  the  address  decoding  of  memory  cells. 
When  data  are  stored  in  incorrect  cells  then  retrieved  from  the  same  incorrect  cells,  the  error 
becomes  self-correcting.  If  the  decoding  error  results  in  an  overlay  operation  where  a word  is 
placed  upon  another,  then  the  output  monitor  would  be  the  main  failure  detector.  However, 
overlays  may  go  undetected  if  data  placed  in  incorrect  cells  are  retrieved  before  that  cell  is 
again  used  during  the  same  iteration.  Such  undetected  failures  can  be  considered  don’t  care 
failures. 

A.6.2.4  Arithmetic  Unit 

The  most  prevalent  latent  failures  within  these  circuits  are  associated  with  moding  and 
functions  unused  during  the  FCD  task  (HSAS  software  program).  However,  it  seems 
reasonable  to  extrapolate  that  these  errors  would  be  registered  by  the  output  monitor  if  the 
functions  had  been  required  in  the  program.  One  potentially  significant  latent  failure  is 
whether  the  increment  selector  can  generate  the  MSB  of  the  data.  In  order  to  establish  this, 
an  output  value  of  at  least  8,  of  a possible  64,  would  have  to  be  exercised.  All  of  the 
remaining  latent  failures  relate  to  the  insertion  of  initial  conditions. 
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FIGURE  A-3.—AL  TERNA  TE  OSCILLA  TOR  COUNTDOWN  AND  WA  VE-SH APING  CIRCUIT 
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CONVERSION  COMPLETE 
FIGURE  A 14.- A/D  CONVERTER 
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FIGURE  A-24.— EFFECTS  OF  FAILING  INPUT  BITS  ON  THE  D/A  CONVERTER 
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FIGURE  A-28.  —PROGRAM  AND  INCREMENT  STORAGE 
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TABLE  A-4.— Continued 


CASE  7 F/F  2 Q STUCK  @ 1 


OUTPUT 


7 /C 


6 n~i6 1 


'250  NSEC 


CASE  8 F/F  2 Q STUCK 


OUTPUT:  STOPS 


TABLE  A -4. -Continued 


CASE  11  F/F  3 Q STUCK  @ 1 


n 

t , 

IB 

n+1 

A 

B 

C 

STATE 

0 

1 

1 

1 

7 

n; 

0 

1 

0 

2 

H 

1 

1 

1 

7 

mm 

0 

1 

1 

3 

n 

1 

1 

1 

7 

ml 

0 

1 

0 

2 

1 

1 

1 

7 

Kfl 

0 

1 

1 

3 

OUTPUT:  STOPS 


CASE  12  F/F  3 Q STUCK  @ 0 


^0 


OUTPUT:  STOPS 


TABLE  A-4.-Continued 


CASE  13  F/F  3 Q STUCK  @ 1 


A B C STATE 


7'  5 


OUTPUT 


500  NSEC 


CASE  14  F/F  3 Q STUCK  @ 0 


OUTPUT:  STOPS 


TABLE  A-4.— Continued 


CASE  15  F/F  3 LOSS  OF  POWER  (Q  & Q = 0 ) 


CASE  16  F/F  3 LOSS  OF  GROUND  (Q  & Q = 1 ) 


—►250  NSEC 


STATE 


4 

4 

5 

5 

6 
6 


MONITOR  RELATED  i ►VOTER  RELATED 


TABLE  A-5.— MATRIX  OF  ALL  POSSIBLE  FAILURE  MODES  FOR  THE  CIRCUIT 

IN  FIGURE  A-4 


SI  - STUCK  - AT  - ONE 
S0  = STUCK  - AT  - ZERO 


FAULT 

NO. 


X-S0  Cl 


X-Sl  G1 


2 -Si  I no 


FFAILN 

X-S0 

SFA1LN 

2-SI 

LFAILN 

2-SI 

R SBC 
KSCA 
SCA 
SBC 


SFAILN 

X-S0 

LFAILN 

X-S0 

J SAB 

X-80 

C SAB 

X-Sl 

K SBC 

X-S0 

R SAB 
K SBC 
J SCA 
C SCA 
SCA* 
SBC* 


SFAILN 

1-SI 

LFAILN 

1-81 

ft 


G2 

X-Sl 

G3 

1-SI 

DO 

2-Sl 

G7  X-S0 


SFAILN 

2 -SI 

LFAILN 

2-Sl 

BC 
C 

K SCA 
R SCA 
SBC 

SAB  X-S#  I SAB* 


FFAILN 

X-Sl 

SFAILN 

S-Sl 

LFAILN 

3 -SI 

C SAB 

X-Sd 

K SBC  X-S* 

R SBC  X-Sl 

C SCA  X-80 

SCA  X-80 

SBC*  X-Sl 


07 

2-Sl  | 

SFAILN 

X-Sl 

LFAILN 

X-Sl 

R SAB 

X-80 

K SBC 

X-Sl 

J SCA 

X-80 

C SCA 

X-Sl 

SCA* 

X-Sl 

K SAB  X-80 


mm « 


TABLE  A-7. -UNDETECTED  FAILURE  MODES  AFTER  ALL  POSSIBLE  INPUT  DATA 

SEQUENCES  (ML  V) 


INPUT  DATA  FAILURES  TO  1 INPUT  DATA  FAILURES  TO 


TABLE  A-8.  — TABULATION  OF  FAULT  SIMULATION  RUNS  MADE 


n 


RUN  LUMBER 

CH  A INPUT 

CH  B INPUT 

— 1 

CH  C INPUT 

FAILURE 

SEQUENCE 

REMARKS 

1 

1 

1 

. 1 

• 

NORMAL  DATA,  ALL  "l's" 

2 

0 

0 

0 

NORMAL  DATA,  ALL  "O’s" 

3 

0 

1 

1 

FIRST  FAIL 

A FAIL  LO 

0 

0 

1 

SEC  FAIL 

B LO,  C HI 

4 

0 

1 

1 

FIRST  FAIL 

A FAIL  LO 

0 

1 

0 

SEC  FAIL 

B HI,  C LO 

5 

1 

0 

1 

FIRST  FAIL 

B FAIL  LO 

0 

0 

1 

SEC  FAIL 

A LO,  C HI 

6 

1 

0 

1 

FIRST  FAIL 

B FAIL  LO 

1 

0 

0 

SEC  FAIL 

A HI,  C LO 

7 

1 

1 

0 

FIRST  FAIL 

C FAIL  LO 

0 

1 

0 

SEC  FAIL 

A LO,  B HI 

8 

1 

1 

0 

FIRST  FAIL 

C FAIL  LO 

k 

1 

0 

0 

SEC  FAIL 

A HI.  B LO 

f 

9 

1 

0 

0 

FIRST  FAIL 

A FAIL  HI 

1 

0 

1 

SEC  FAIL 

B LO,  C HI 

10 

1 

0 

0 

FIRST  FAIL 

A FAIL  HI 

1 

1 

0 

SEC  FAIL 

B HI,  C LO 

11 

0 

1 

0 

FIRST  FAIL 

B FAIL  HI 

0 

1 

1 

SEC  FAIL 

A LO,  C HI 

12 

0 

1 

0 

FIRST  FAIL 

B FAIL  HI 

1 

1 

0 

SEC  FAIL 

A HI,  C LO 

13 

0 

0 

1 

FIRST  FAIL 

C FAIL  HI 

0 

1 

1 

SEC  FAIL 

A LO,  B HI 

14 

0 

0 

1 

FIRST  FAIL 

C FAIL  HI 

L 

1 

0 

1 

SEC  FAIL 

A HI,  B LO 

186 


TABLE  A-9.-FAILURES  DETECTED  BY  PROCESSING  NORMAL  DATA 


RUN  1 & 2 


RUN  1 


RUN  2 


FAULT 

NO. 

o' 

w 

K 


Monitoring:  DO,  FFAILN,  SFA1LN,  LFAII.N 
Gl  X-Sl  | G1  1 

G2 


G2 

X-Sl 

G3 

1-SI 

DO 

2 -SI 

2 -Si  « 


SFA1LN 

2 -SI 

LFA1LN 

2 -SI 

FFAILN 

X-Sl 

SFA1LN 

3 -SI 

LFA1LN 

3 -Si 

C SAB 

X-S6 

K SCA 
RSCA 
SBC 
SAB 


J SAB 

x-sl 

C SAB 

X-Sl 

K SBC 

X-S| 

R SBC 

X-Sl 

C SCA 

X-S| 

SCA 

x-sl 

SBC* 

X-Sl 

G7 

2-SI 

SFA1LN 

X-Sl 

LFA1LN 

X-Sl 

R SAB 

X-S| 

K SBC 

X-Sl 

J SCA 

x-sl 

C SCA 

X-Sl 

SCA* 

X-Sl 

MONITOR  RELATED  -*T*-VOTER  RELATED 


TABLE  A-10.-FAILURE  DETECTED  BY  VARIOUS  COMBINATIONS  OF  FIRST 

AND  SECOND  FAILURE  SEQUENCE 

RUN  3 

First  Fall 

Second  Fall 

Sequence 

Sequence 

CH  A 

0 

0 

CH  B 

1 

0 

CH  C 

1 

1 

FAULT 

HO.  Monitoring: 

DO.  FFA1LN.  SFAILN,  LFAILN 

G3  1-SI 

I 

DO 


04  2-Sl  I G4 

GS  1-SI 

G6  X-Sl  I G6 


FFAILN  X-S0 


LFAILN  2-SI 


SFAILN 


K SCA 

x-s* 

R SCA 

X-Sl 

X-Sl  Gl 


3-Sl 

3-81  | G 


1-SI  G6 
X-Sl  G7 


G5 

4-SI 

G6 

3 -Si 

G7 

2-Sl 

G3 

X-Sl 

DO 

1-SI 

G4 

1-Sl 

-G4 

-XSt 

G6 

4-Sl 

G7 

3 -Si 

SFAILN 

1-Sl 

LFAILN 

1-Sl 

K SAB 

X-8| 

R SAB 

X-Sl 

J SCA 

X-Sl 

SCA*  X-Sl 


TABLE  A- 10.— Continued 


First  Fall 
Sequence 


Second  Fall 
Sequence 


25  w 


Monitoring:  DO,  FFA1LN.  SFAILN,  LFAILN 


G1 
G2 

G3  1-SI  ! G3 


DO 


2-SI  I G4 
1-Sl 
X-Sl  | G6 


FFA1LN  X-S # 


LFAILN  2-SI 


SFAILN 


G5 

4-SI 

G6 

3-81 

G7 

2-SI 

SFAILN 

1-Sl 

LFAILN 

1-Sl 

K SCA 

x-s# 

R SCA 

X-Sl 

K SBC  X-S# 

R SBC  X-SI 


SCA*  X-Sl  I SC 


SAB*  X-Sl  | SAB*  X-S# 

Indicates  logical  complement 

Failures  detected  by  fall  sequence 

Additional  failures  detected  by  second  fall  sequence 


TABLE  A- 10.  —Continued 


RUN  5 


First  Fail 
Sequence 

CH  A 1 

CH  B 0 

CH  C 1 


Second  Fail 
Sequence 


Monitoring:  DO.  FFAILN.  SFA1LN.  LFAILN 


-SI  01 


G2 

X-81 

G3 

1-SI 

DO 

2 -SI 

FFAILN 

X-S| 

SFAILN 

2 -SI 

LFAILN 

2-Sl 

G4 

3-81 

GS 

2-81 

Gfl 

1-81 

G7 

X-81 

KSCA 

X-S| 

R SC  A 

X-81 

SBC 

X-81 

G4 

4-81 

G5 

3-81 

J SBC  X-Sl  | K SBC  X-8| 

R SBC  X-Sl 


LFAILN 

X-81 

J SAB 

X-Sl 

G6 

4-81 

G7 

3-81 

SFAILN 

1-SI 

LFAILN 

1-81 

K SAB 

X-81 

R SAB 

X-Sl 

SAB*  X-Sl  | SAB*  X-S| 

* Indicates  logical  complement 

Failures  detected  by  first  fail  sequence 
Additional  failures  detected  by  second  fall  sequence 


Firat  Fail 
Sequence 


CH  A 1_ 

CH  B 1_ 

CH  C 0 


TABLE  A- 10. -Continued 


Monitoring:  DO.  FFA1LN.  SFAILN,  LFAILN 


Second  Fall 
Sequence 


02 

X-Sl 

G2 

1-81 

G3 

1-SI 

G3 

2-81 

DO 

2-81 

DO 

3-81 

OS 

1-SI 

04 

X-Sl 

-Of 

FFAILN 

x-8| 

SFAILN 

2 -SI 

LFAILN 

2-81 

K SAB 

X-81 

K8CA 

X-80 

R SCA 

X-81 

SBC 

X-81 

K SBC  X-80 

R SBC  X-Sl 


04 

4-81 

OS 

S-Sl 

G4 

2-81 

07 

1-81 

OS 

4-81 

04 

3-81 

07 

2-81 

LFAILN  X-81  | LFAILN  1-81 


| SAB*  X-Sl  j SAB*  X-80 

* Indicates  logical  complement 

Failures  detected  by  first  fall  sequence 
Additional  failures  detected  by  second  fall  sequence 


Ait* 


First  Fail 
Sequence 


CH  A 1_ 

CH  B 1_ 

CH  C 0 


TABLE  A-IO.-Contmued 


Second  Fall 
Sequence 


FAULT 

NO. 


Monitoring:  DO.  FFAILN.  8FAILN.  LFAILN 


sl  i 

35  g 


G2 

X-Sl 

DO 

2-Sl 

44 ft-A 

G5 

1-81 

GS 

X-Sl 

M-S# 

FFAILN 

x-s| 

8FAILN 

2-81 

LFAILN 

2-Sl 

K SAB 

X-Sl 

G2 

1-81 

G3 

2 -SI 

DO 

3-SI 

G4 

4-Sl 

G5 

3 -SI 

GS 

2-Sl 

G7 



1-Sl 

LFAILN  X-Sl  I LFAILN  1-SI 


K-fi*  | SAB*  X-Sl  | SAB*  X-S| 

* Indicates  logical  complement 

Failures  detected  by  first  fall  sequence 
Additional  failures  detected  by  second  fail  sequence 


RUN  9 

TABLE  A- 10.— Continued 

First  Fall 
Sequence 

Second  Fall 
Sequence 

CH  A 

1 

1 

CH  B 

0 

0 

FAULT 

NO. 

CH  C 
Monitoring: 

0 

DO,  FFAILN,  SFAILN,  LFAILN 

1 

DO  2-81 


FFAILN  X-80 


LFAILN  2-SI 


X-Sl  01 


G2 


04 

3-81 

OS 

2-81 

Gfl 

1-Sl 

07 

X-Sl 

SFAILN 

3-81 

3 -Si 
2-81  G6 

1-Sl  07 


DO  1-81 


04  1-Sl 


K SCA  X-S* 

R SCA  X-Sl  I SC 


K SBC  X-80 

H SBC  X-Sl 


| SAB*  X-Sl  j SAB*  X-80  ) 

* Indicator  logical  complement 

Failures  detected  by  first  fall  sequence 
. Additional  failures  detected  by  second  fall  sequence 


TABLE  A- 10.  -Con tinned 

RUN  10 

First  Fail 
Sequence 

Second  Fail 
Sequence 

CH  A 1 

1 

CH  B 0 

1 

CH  C 0 

0 

FAULT 
WO.  _ 

Monitoring:  DO.  FFAILN,  SFAILN.  LFAILN 

• 

DO  3-81  I DO 


04  1-81  04 


FFA1LN  X-8# 


LFA1LN  1-81 


01 

1-81 

03 

1-81 

DO 

3-81 

04 

3-81 

05 

3-81 

04 

1-SI 

07 

X-81 

04 

3-81 

07 

3-81 

8FAILN 


SFAllJf 

1-81 

LFALN 

1-81 

K8BC  X-8#  | K SBC 

R SBC  X-81 


K8CA 
R 8CA 


SAB*  X-81  | SAB*  X-8# 

* Indicates  logical  complement 

Failures  detected  by  first  fail  sequence 
Additional  failures  detected  by  second  fail  science 


TABLE  A-  iO.— Continued 


RUN  11 


First  Fail 
Sequence 


Second  Fail 
Sequence 


Monitoring:  DO,  FFA1LN,  SFA1LN.  LFA1LN 


04 

2-81 

G5 

1-SI 

G1 

X-Sl 

G2 

1-81 

G3 

2 -SI 

DO 

3-81 

K SCA 

X-S# 

RSCA 

X-Sl 

SBC 

X-Sl 

04 

4-Sl 

GS 

3 -SI 

G6 

2-Sl 

G7 

1-Sl 

G5 

4-Sl 

OS 

3 -SI 

07 

2 -SI 

^ Q| 

LFAILN 

X-Sl 

J SAB 

X-Sl 

K SBC 

x-sl 

R SBC 

X-Sl 

07 

3 -Si 

SFA1LN 

1-Sl 

LFAILN 

1-Sl 

K SAB 

X-S0 

R SAB 

X-Sl 

SAB*  X-Sl  | SAB*  X-S0 

* Indicates  logical  complement 

Failures  detected  by  first  fall  sequence 
Additional  failures  detected  by  second  fail  sequence 


TABLE  A-10.— Continued 


RUN  12 


■ First  Fall 
Sequence 


Second  Fall 
Sequence 


FAULT 

NO. 

a" 
_ w 

I H 


CH  A 0 

CH  B 1 

CH  C 0 

Monitoring;  DO.  FFAILN,  SFAILN.  LFAILN 


G2 

X-Sl 

G2 

1-SI 

G3 

1-81 

G3 

2-Sl 

DO 

2-Sl 

DO 

3-81 

25  g 

“ i 

35  g 


2-81  04 

1-SI  05 


FFAILN 

X-Sf) 

SFAILN 

2-Sl 

LFAILN 

2-Sl 

KSCA 

x-sl 

R SC  A 

X-Sl 

SBC 

X-Sl 

04 

- — wpif 

4-81 

05 

3 -Si 

05 

2-Sl 

07 

1-SI 

■a 

05 

4-SI 

06 

3 -SI 

07 

2-81 

LFAILN 

X-Sl 

J SAB 

X-Sl 

SFAILN 

1-SI 

LFAILN 

1-SI 

K SBC 

x-s| 

R SBC 

X-Sl 

SAB*  X-Sl  | SAB*  X-S# 

* Indicates  logical  complement 

Failures  detected  by  first  fail  sequence 
_ Additional  failures  detected  by  second  fail  sequence 


I 


^1 


TABLE  A- 10.— Continued 


RUN  13 


First  Fall 
Sequence 


FAULT 

NO. 

a ~ 
w 
H 

d 

w 
tf 

K 
W 
H 

£ 


Monitoring:  DO.  FFA1LN.  SFAILN.  LFA1LN 


G 


1-SI 

I 

DO 


2-Sl  1 04 


2-Sl 


1-Sl  G5 
X-Sl  G6 


FFAILN 

X-S* 

SFAILN 

2 -SI 

LFAILN 

2 -Si 

K SAB 

X-81 

KSCA 

X-S0 

RSCA 

X-Sl 

SBC 

X-Sl 

X-Sl  SAB*  X-S# 


Second  Fall 
Sequence 


G1 

1-Sl 

G2 

2 -SI 

LFAILN  X 


K SBC 

x-srf 

R SBC 

X-Sl 

G3  X-81 

DO  1-81 


GS 

3-SI 

05 

4-SI 

G6 

2-81 

06 

3-81 

07 

1-Sl 

07 

2-Sl 

G5 

X-81 

14mm 

G6  4-SI 

G7  3-81 


LFAILN  I-Sl 
K SAB  X-80 

R SAB  X-Sl 


* Indicates  logical  complement 

Failures  detected  by  first  fall  sequence 
Additional  failures  detected  by  second  fall  sequence 


MW 

i SC  A 

X-Sl 

SCA* 

X-80 

4 

I 


RUN  14 

TABLE  A-10.- 

■Concluded 

First  Fail 
Sequence 

Second  Fall 
Sequence 

CH  A 

0 

1 

CH  B 

0 

0 

CH  C 

1 

1 

FAULT 
NO.  _ 

Monitoring 

: DO.  FFAILN.  SFAILN, 

, LFAILN 

X-Sl  ul 


25  u 

» I 

Bt 

35  Pi 


FFAILN 

X-SfJ 

SFAILN 

2-SI 

LFAILN 

2-SI 

K SAB 

X-81 

G4 

3-81 

GS 

2-81 

G6 

1-81 

G7 

X-81 

3-Si 
2-81  G6 

1-81  G7 


K SCA  X-S* 

R SCA  X-Sl  SC 
SBC  X-81 

«*•  I SAB* 


X-Sl  SAB*  X-81 


LFAILN  X-81  ILFAILN  1-81 


K SBC 

x-srf 

R SBC 

X-81 

Indicates  logical  complement 

Failures  detected  by  first  fail  sequence 

Additional  failures  detected  by  second  fall  sequence 


99 


TABLE  A-12.-SSFD  FMECA  RESULTS 


TABLE  A- 13.  -Continued 


206 


TABLE  A- 14.  -COMPUTER  FMECA 


TABLE  A- 14.  -Continued 


instruction  Stuck  to  address  I No  register  parity  bit  inserted  into 


Table  A- 14—  Continued 


APPENDIX  B 


1 


* ICPS  PREFLIGHT  TEST 

i 

I 

The  FMECA  study  results  presented  in  appendix  A show  several  design  areas  of  the 
c ICPS  that  contain  undesirable  failure  mode  effects.  Notable  among  these  was  the 

fail-operative  clock  circuit.  In  this  case,  the  circuit  was  redesigned,  reevaluated,  and  a change 
implemented  to  remove  the  damaging  failure  mode.  All  other  undesirable  failure  modes  are 
latent  in  nature,  where  the  associated  circuits  cannot  be  easily  changed  to  circumvent  the 
problem.  These  areas  of  the  system  must  be  tested  to  ensure  operational  integrity.  This 
appendix  presents  the  results  of  the  limited  preflight  test  laboratory  investigations 
conducted  with  the  ICPS,  preceded  by  a discussion  of  the  required  tests  on  the  MLV  and 
its  monitor,  to  establish  that  those  circuits  do  not  contain  latent  failures. 


B.l  MAJORITY  LOGIC  VOTER  MONITOR 

In  appendix  A,  it  was  pointed  out  that  the  processing  of  normal  data  (channel  A = 
channel  B = channel  C)  would  not  uncover  certain  failures  within  the  MLV  and  its  monitor. 
In  order  to  clear  such  faults,  all  combinations  of  incoming  data  states  would  be  required.  A 
method  to  check  the  MLV,  short  of  manipulating  all  input  failure  states,  was  proposed  with 
the  addition  of  the  circuit  elements  illustrated  in  figure  B-l.  These  elements  allow  the 
insertion  of  a fail-to-high  condition  on  the  channel  A and  B paths.  The  proposed  built-in  test 
electronics  were  evaluated  to  determine  what  test  series  would  be  required  to  detect 
previously  undetected  failure  modes. 

Applying  the  same  failure  mode  analysis  methods  used  in  section  A.2,  the  effectiveness 
of  using  the  BIT  elements  to  uncover  the  possible  failure  modes  is  tabulated  in  table  B-l. 
(Nomenclature  for  this  table  is  the  same  as  used  in  tables  A-9  and  A-10.)  This  table  was 
compiled  by  using  simulation  runs  1,2,  10,  and  12  from  table  A-10  (assuming  no  faults  in 
the  BIT  circuits).  These  runs  represent  the  MLV  circuit  operation  with  normal  (nonfailed) 
data  inputs  and  the  first  and  second  failure  sequences  where  channels  A and  B fail  high 
through  the  use  of  the  BIT  circuitry.  Each  of  the  potential  failure  modes  that  are  detected 
are  annotated  in  table  B-l  by  identifying  the  various  conditions  under  which  the  failures 
were  detected.  The  failure  modes  that  can  be  detected  through  the  processing  of  normal 
data  (channel  A = channel  B = channel  C)  are  crossed  out  with  a thin  line  while  those 
detected  by  the  proposed  BIT  circuitry  are  crossed  out  with  a heavy  line.  The  failure  modes 
in  table  B-l  that  are  shown  closed  in  a rectangle  are  the  never  detected  failure  modes 
discussed  in  section  A.2. 3.  The  remaining  undetected  failure  modes  of  concern  have  been 
circled  by  a squiggly  line.  As  can  be  noted  from  the  table,  many  of  the  undetected  potential 
failures  are  still  within  the  voter  section  of  the  design. 

By  reviewing  the  testing  sequence  made  possible  with  the  BIT  circuitry,  one  can 
t ascertain  that  there  are  four  possible  ways  to  force  a first  and  second  failure  sequence  by 

causing  input  failures  to  only  two  of  the  three  channels.  The  proposed  BIT  circuitry, 
discussed  above,  failed  channel  A and  B high.  The  three  additional  sequences  are: 


I 


• Failed  channel  A high;  failed  channel  B low  (condition  11) 

• Failed  channel  A low;  failed  channel  B high  (condition  111) 


•» 


• Failed  channel  A low;  failed  channel  B low  (condition  IV) 

These  three  additional  combinations  were  explored  to  see  if  they  resulted  in  a more 
optimum  BIT  sequence.  The  results  are  condensed  in  tables  B-2  through  B-4.  By  viewing 
these  results,  it  is  obvious  that  none  of  the  alternate  BIT  test  conditions,  uniquely  or 
collectively,  present  a complete  test.  Therefore,  it  appears  that  the  earlier  analysis  in 
appendix  A requiring  failure  states  to  be  placed  on  all  data  paths  must  be  adhered  to. 

However,  not  all  input  data  combinations  need  to  be  tested.  If  the  extra  redundancy 
links  (those  elements  inside  the  rectangles  in  table  B-l)  are  deleted  either  by  removing  one 
of  the  first  two  inputs  to  gate  G-7  (see  fig.  A-4)  or  by  removing  one  of  the  first  two  inputs 
into  gate  G-9,  the  minimum  test  sequence  presented  below  will  suffice. 

Test  1 Failed  channel  A high;  then  seeond  failed  channel  B high 

Failed  channel  B high;  then  second  failed  channel  C high 
Failed  channel  C high;  then  second  failed  channel  A high 
or 

Test  2 Failed  channel  A low;  then  second  failed  channel  B low 
Failed  channel  B low;  then  second  failed  channel  C low 
Failed  channel  C low;  then  second  failed  channel  A low 

(Test  1 and  2 are  complements  of  each  other.)  Thus,  only  three  failure  sequences  of  the 
possible  six  are  required  to  totally  check  the  MLV  and  its  monitor. 
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B.2  LABORATORY  ICPS  PREFLIGHT  TEST 

An  abbreviated  preflight  test  of  the  ICPS  was  evaluated  in  the  laboratory.  The  test 
could  not  be  automated  because  two  essential  elements  were  not  availabe.  The  first  was  the 
lack  of  an  automatic  test  administrator.  It  is  anticipated  that  such  a device  would  supply  the 
needed  stimuli  and  process  the  resultant  responses  to  ascertain  the  go/no-go  status  of  the 
subsystem.  To  account  for  this  shortcoming,  the  stimuli  had  to  be  manually  induced.  The 
second  element  missing  was  the  BIT  test  circuits  (like  those  mentioned  above)  to  control 
and  check  t^e  monitoring  functions  within  the  ICPS.  Therefore,  the  laboratory  test  had  to 
assume  that  the  monitors  were  working  even  though  a proper  preflight  test  would  include 
checking  the  monitors  as  a first  step.  This  is  required  since  the  monitors  are  used  to  detect 
any  improper  response  resulting  from  prefiight  test  stimuli. 

The  test  procedure  developed  assumed  on-the-ground  conditions  and  that  all  hydraulic 
and  electrical  power  were  on.  System  stimuli  for  the  test  sequence  involved  exercising  the 
column  and  pitch-rate  gyro  signals  to  generate  a triangular  waveform  input  to  the  ICPS  of 
±4V  at  0.2  Hz.  The  settings  of  the  hardware  SSFD  parameters  (illustrated  in  fig.  4-1 1)  for 
the  signals  monitored  are  tabulated  in  table  B-5.  For  each  of  the  postulated  failures  in  table 
B-6,  the  preflight  test  was  cycled  to  check  if  the  failure  was  detected  by  any  ICPS  monitor. 
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The  results  of  the  ICPS  laboratory  preflight-test  tests  are  presented  in  table  B-6.  The 
following  paragraphs  summarize  conclusions  drawn  from  the  test  results,  by  failure 
category,  as  referenced  to  the  test  numbers  of  table  B-6. 

Senior  Input  Failures  (t  sts  1 through  7) 

Single-sensor  passive  failures  are  easily  detected,  and  the  appropriate  faulty  channel  are 
identified.  Two  like  passive-sensor  failures  will  be  detected,  but  the  good  channel  will  be 
identified  as  the  local  failure.  All  other  input  sensor  failures  were  detected  and  identified. 

Inter-  and  Intra-Cable  Disconnects  (tests  8 through  1 2) 

Disconnected  cables  resulted  in  failure  indications  for  all  cases.  As  anticipated,  system 
input  stimuli  were  required  to  uncover  data  path  failures  to  interfacing  subsystems,  where 
data  path  separations  within  the  subsystem  were  immediately  detected.  Some  cable 
separations  produced  a second  failure  indication.  The  system  remained  operational,  but  the 
failure  annunciation  panel  indicated  a second  failure  from  one  channel.  This  points  up  the 
need  to  vote  second-failure  failure  status  logic  if  it  is  going  to  be  used  to  automatically  shut 
down  a channel  or  system. 

Power  Failures  (tests  1 3 and  1 4) 

Total  power  failure  in  any  ICPS  LRU  is  immediately  detected.  Since  input  power  is 
dual,  loss  of  a single  power  source  did  not  result  in  either  a system  failure  or  a first  fail  light. 
The  only  indication  of  this  condition  was  displayed  by  the  computer  mechanical  BIT 
indicator  on  the  LRU  and  the  channel  local  failure  annunciator. 

Computer  Memory  Failures  (tests  15  through  24) 

Changes  in  program  memory  were  hand  inserted  into  various  memory  locations  to 
simulate  failures.  These  tests  were  included  in  order  to  obtain  a sensitivity  of  the  system 
monitoring  to  memory  failures.  In  all  cases,  except  one,  the  bit-by-bit  output  voter  monitor 
detected  the  changes,  and  a first  failure  was  annunciated.  This  was  true  even  for  test  15 
where  the  large  Sq  term  was  changed  from  4737  to  4738.  Gyro  torquing  was  necessary, 
however,  to  produce  the  bit  difference  required  for  the  monitor  to  trip.  The  case  that  did 
not  produce  a first  failure  indication  (test  1 6)  related  to  a change  in  an  algorithm  not  used 
in  the  operational  program.  This,  however,  produced  no  system  failure  indications  and  is 
considered  a don’t  care  failure.  In  all  cases,  the  computer  BIT  circuitry  detected  a parity 
error  and  annunciated  the  ROM  and  local  failure  lights. 


FIGURE  B- 1.  —PROPOSED  ICPS  BUILT-IN-TEST  ELECTRONICS  FOR  MAJORITY  LOGIC  VOTERS 


TABLE  B-1 -UNDETECTED  FAILURE  MODES  WITH  USE  OF  BIT  CIRCUITRY 


FAILURE  MODES  DETECTED  WITH  NORMAL  DATA  - 

ADDITIONAL  FAILURE  MODES  DETECTED  WITH  BIT 
CIRCUITRY  (A  FAIL  HI,  B FAIL  HI) 


Runs  10,  12 


FAULT 


SFAILN  1-SI 


FAILN  1-81 


LFA1LN  2-31 


TABLE  B-2. -PATTERN  OF  UNDETECTED  FAILURE  MODES  OF  CONCERN 

AFTER  BIT  CONDITION  II 


Compiled  from  Runs  1,  2,  6,  and  9. 
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TABLE  B-5.— FAILURE  MONITOR  PARAMETER  VALUES 
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TABLE  B-6.—ICPS  LABORA  TORY  PREFLIGHT  TEST  RESUL  TS  (HSAS) 
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APPENDIX  C 
WWCS  FMECA 


This  appendix  contains  the  various  FMECA  studies  conducted  on  the  WWCS.  The 
redundancy  structure  was  partitioned  into  the  first-  and  second-level  FMECA  areas  of 
concern  as  discussed  in  section  3.2.  Elements  of  the  WWCS  similar  or  identical  in  design  to 
elements  of  the  1CPS  were  not  reevaluated.  These  elements  included  the  redundant  clock, 
majority  logic  voter/monitor  and  analog  input/output  circuitry,  and  associated  timing.  Level 
one  WWCS  elements  analyzed  and  presented  are  the  device  controller  interface,  SSCU 
interface,  and  servotransmitter/receiver  interface.  Second  level  functions  covered  included 
the  WWCS  synchronous  logic  interface,  memory,  and  central  processor. 


C.l  DEVICE  CONTROLLER 

The  device  controller  interface  is  used  as  a communication  path  to  and  from  the  WWCS 
central  processor  (CP)  and  other  subsystems  (or  system  elements)  over  which  the  CP  has 
little  or  no  timing  control.  While  the  device  controller  interface  to  the  CP  is  in  general  a 
common  design,  the  transmitter/receiver  circuits,  which  interface  with  each  external 
subsystem,  are  specifically  designed  to  satisfy  the  unique  characteristics  of  each  subsystem. 
Further,  the  failure  effect  of  the  circuits  within  the  device  controller  will  depend  in  large 
upon  the  software  design  associated  with  the  particular  interface.  A block  diagram  showing 
the  general  design  of  a device  controller  is  shown  in  figure  C-l . 

In  general,  the  device  controller  timing  and  control  section  obtains  the  attention  of  the 
CP  through  the  generation  of  an  interrupt  signal.  The  processor  will  respond  to  the  interrupt 
by  interrogating  the  requesting  device  controller’s  address  and  by  jumping  to  the 
appropriate  software  subroutine  which  handles  that  I/O  interface.  The  interrupt  feature  can 
be  interlocked  to  prevent  an  outside  subsystem  from  interrupting  the  CP,  whereby  .he 
device  controller  is  serviced  strictly  under  CP  program  control. 

To  resolve  the  problem  of  having  a number  of  device  controller  simultaneously 
requesting  CP  service,  a priority  system  is  used.  The  priority  is  established  through  computer 
unit  harness  wiring.  The  ordering  of  these  priorities  in  the  WWCS  are: 

First  and  second:  Cross  channel  receivers  (from  the  other  two  channel  computers) 

Third:  Computer  monitor  and  control  unit  (CMCU) 

Fourth:  Tape  reader 


Fifth: 


Paper  punch 


The  priority  system  is  mechanized  so  that  a higher  order  device  disables  any  lower 
ordered  device  from  requesting  service.  The  remaining  device  controller  interfaces  (SSCU, 
X -channel  transmitter,  and  failure  status  and  BIT  discretes)  do  not  have  priorities  because 
their  design  is  such  that  they  do  not  generate  an  interrupt.  These  interfaces  are  serviced 
exclusively  by  program  sequence  in  the  WWCS  executive  routine. 


Once  the  processor  responds  to  an  interrupt,  it  locks  out  the  priority  structure  so  that 
the  device  being  interrogated  is  not  disabled  by  a higher  priority  device.  Once  the  CP  has 
finished  with  a device,  any  devices  still  requesting  service,  under  established  priorities,  can 
send  an  interrupt  to  the  processor.  The  processor  also  has  the  ability  to  either  selectively 
mask  a device  interface  or  to  mask  them  all.  This  capability  allow*  any  single  device  or  the 
entire  processor-controlled  interface  section  to  be  ignored  or  masked  during  critical  program 
calculations. 

Interaction  of  the  hardware/softwarc  utilization  of  a device  controller  interface  can  be 
typified  by  an  evaluation  of  the  WWCS  computers  cross-channel  circuits.  The  following, 
therefore,  presents  a description  of  the  WWCS  cross-channel  device  controllers,  an  FMECA 
for  their  utilization  within  the  WWCS  laboratory  studies,  and  the  ramifications  of  the 
cross-channel  hardware/software  if  the  interface  were  used  within  a flight-critical  program. 


C.l  .1  Cross-Channel  Device  Controller  Transmitter/Receiver  Description 

I here  are  two  cross-channel  receivers  in  each  MCP-703  computer  unit  for  receiving 
data  transfers  from  the  other  two  computer  units.  The  receiver  circuits  are  activated  by  the 
leading  one  in  an  18-bit  data  transmission  train.  This  marker  bit  is  latched  in  order  to 
provide  an  enabling  signal  to  allow  the  shift  register  to  acquire  the  data  and  to  allow  a 
coordinating  counter  to  run.  Upon  reaching  the  count  of  16,  the  enable  is  cleared  and  a 
desirc-for-service  request  (SET)  is  sent  to  the  device  controller  timing  circuits  to  establish  an 
interrupt.  The  last  bit  of  the  18-bit  transmitted  word  is  a parity  bit.  Figure  C-2  shows  the 
logic  of  the  cross-channel  interface  receiver  design. 

Upon  CP  recognition  of  the  interrupt,  the  first  word  taken  (take)  will  contain  the  valid 
(parity)  designator.  The  first  take  will  also  toggle  the  multiplex  control  that  clears  the  parity 
checker  and  enables  the  data  to  the  buss  buffer.  The  second  take  can  then  acquire  the  data. 

The  receiver  device  controller  timing  and  control  circuits  are  shown  in  figure  C-3. 
These  circuits  are  relatively  complex  because  the  receiver  device  controller  interface 
operates  under  interrupt  control  or  under  computer  service  control,  with  the  CP  also  able  to 
selectively  prevent  interrupts.  Operation  of  this  section  centers  about  the  three  events 
(states)  of  ready,  select,  and  mask.  The  receiver  sets  the  ready  state  when  it  desires  service 
by  the  computer.  The  select  state  is  then  set  by  the  ready  state  if  no  other  device  is  already 
being  serviced  (I/O  lock)  and  the  device  is  not  masked  to  prevent  interrupts.  The 
combination  of  ready  and  select  is  used  to  drive  the  interrupt  line  to  the  computer 
(request).  Once  the  computer  has  responded  to  this  interrupt,  the  higher  priority  devices  are 
prevented  from  disturbing  the  system  by  having  them  disabled  (I/O  lock).  The  I/O  lock 
prevents  the  ready  signal  from  passing  onto  the  select  logic. 
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The  priority  system  is  established  about  the  select  state.  It  is  so  constructed  that  any 
select  will  clear  any  other  selects  that  are  lower  in  priority.  Thus,  only  one  select  can  be  set 
at  any  one  instant.  Thereby  the  select  state  indicates  which  device  interface  ^ going  to  be 

serviced  by  the  computer.  v 

The  CP  can  also  set  the  select  with  the  sel  instruction.  The  address  portion  of  this 
instruction  directs  which  interface  is  to  be  set.  Also,  the  execution  of  this  sel  instruction 
unselects  any  other  device  that  might  be  set. 


The  third  state,  mask,  performs  a similar  function  as  the  I/O  lock,  except  that  this  ^tate 
is  set  by  the  computer  on  an  individual  device  interface  basis. 

The  ready  state  is  cleared  either  by  CP  sen-icing  or  by  a reset  instruction.  The  select 
state  is  cleared  by  the  reset  instruction  or  by  the  selection  of  another  device.  Mask  is  cleared 
by  the  sel  instruction  of  its  own  device  or  globally  (all  mask’s)  with  a device  enable 

instruction. 


The  transmitter  side  of  the  cross-channel  interface  (fig.  C-4)  is  completely  controlled 
by  the  CP  through  the  computer  program.  The  transmitter  device  controller  must  be 
addressed  using  the  select  instruction,  which  enables  the  transmitter  circuitry,  and  must  be 
activated  through  the  use  of  a put  instruction.  Upon  the  execution  oi  the  put  instruction, 
data  in  the  MCP-701  upper  register  are  transferred  to  the  transmitter  shift  register,  and 
transmission  is  initiated. 

The  16-bi*  data  word  is  transferred  to  the  cross-channel  receivers  as  an  18-bit  word. 
The  fust  bit  is  a marker  bit  (“1”)  that  is  required  to  turn  on  the  receiver.  This  is  followed  by 
the  data  (LSB  first)  then  the  parity  bit.  This  data  string  is  sent  at  a 2.5  MHz  clock  rate 

derived  from  the  CP  clock. 


Provision  is  made  to  prevent  the  CP  from  initiating  a second  transmission  before  the 
first  is  complete.  This  is  accomplished  through  the  use  of  ANDing  the  select  state  and  the 
fact  that  the  transmitter  is  idle.  This  ANDed  signal  is  then  placed  onto  the  interrupt  buss  tor 
device  controllers.  Signals  on  this  buss  set  the  device  ready  bit  of  the  computer  (CP)  status 
register.  This  bit  can  be  interrogated  through  software  to  defer  a second  transmission  (put 
instruction)  until  the  device  is  ready. 

The  transmitter  timing  sequence  is  essentially  a counter  and  a couple  of  flip-flop 
devices  mechanized  as  a shift  register.  Receipt  of  the  initiate  signal  inserts  a control  bit  into 
the  shift  register  that  sends  out  the  marker  bit.  It  then  shifts  to  enable  the  counter  and 
transmitter  for  16  counts.  Following  this,  the  control  bit  is  shifted  to  enable  the  parity  bit 
onto  the  transmission  line.  Finally,  the  control  bit  clears  the  counter  and  the  parity  checker. 


The  integrity  check  on  the  transmitter  is  by  a parity  check  at  the  receiver.  As  a means 
to  provide  a check  on  this  monitor,  the  ability  to  complement  the  parity  bit  is  provided. 
This  function  is  exercised  by  the  computer  self-test,  BIT  program. 
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C.l  .2  Cross-Channel  FMECA 


f 


Chief  concern  of  the  cross-channel  interface  is  whether  there  is  a failure  possibility  in  a 
single  transmitter  that  could  cause  the  receivers  in  the  other  two  channels  to  encumber  their 
respective  CP’s.  Such  an  event  would  present  a single  point  failure  that  could  result  in  a 
total  system  malfunction.  A failure  effect  analysis  of  the  transmitter/receiver  failure  modes, 
delineated  in  table  C-l,  established  that  there  were  several  failures  that  could  cause  a 
continual  request  for  servicing  of  the  attached  receivers. 

To  assess  the  impact  on  the  system,  the  resident  software  was  checked  to  see  how  the 
cross-channel  interface  was  utilized.  If  the  interface  is  operated  strictly  on  an  interrupt  basis 
(i.e.,  service  when  requested),  system  operation  can  be  severly  impacted  by  the  time 
required  to  service  the  interface.  Even  if  the  validity  test  indicates  a failure,  time  is  still 
required  to  link  up  the  interface  to  determine  that  fact.  If  the  interface  is  used  totally  under 
CP  control,  no  hardware  failures  appear  to  affect  the  system  operation. 

A review  of  the  WWCS  in-flight  application  resident  program  showed  that  cross-channel 
exchanges  are  only  used  by  the  WWCS  executive  (level  I)  program  for  initialization  after 
power  turn-on  and  for  frame  synchronization  of  the  three  computers  following  a 
computational  reset  command.  Both  of  these  cross-channel  exchanges  utilize  CP  control  of 
the  interface  and  mask  the  interrupt  operation. 

Device  controller  interrupts  were  not  allowed  during  the  processing  of  the 
flight-control  law  (level  II)  program  to  satisfy  strict  redundant-operation  timing 
requirements.  Device  controller  interrupts  were,  however,  required  in  the  background  (level 
111)  program  to  service  the  computer  monitor  and  control  unit  when  this  unit  is  coupled  to 
the  WWCS  equipment.  The  CMCU  is  a laboratory  support  unit  and  would  not  be  a part  of 
the  system  in  actual  flight  operations.  Further,  the  CMCU  program  does  not  utilize  the 
cross-channel  interface. 

The  only  utilization  of  the  cross-channel  interface,  outside  the  executive  (level  I) 
program  use  mentioned  above,  was  within  the  preflight  test  (level  IV)  program.  This 
program  is  made  up  of  the  WWCS  BIT  and  the  application  model  PHT.  These  tests  are 
conducted  as  a ground /laboratory  operation  only  and  are  double  interlocked  to  prevent 
their  operation  in-flight. 

It  was  determined  from  this  analysis  of  the  WWCS  mechanization  of  the  application 
(HSAS)  flight-control  system  that  no  critical  failure  modes  existed  within  the  cross-channel 
interface.  This,  however,  reflects  a specific  WWCS  configuration  use  of  the  cross-channel 
interface.  In  order  to  provide  a better  understanding  of  the  software/hardware  interaction 
for  such  an  interface  from  the  FMECA  point  of  view,  the  following  discussion  is  presented 
on  the  use  of  the  cross-channel  interface  with  the  level  11  (control  law)  resident  program. 

C.l. 3 Flight-Critical  System  Use  of  Cross-Channel  Interface 

If  the  flight  resident  software  were  to  be  restructured  so  that  cross-channel  transfers 
were  to  be  made  between  computer  units  to  improve  redundancy  management  during  level 
II  program  execution,  several  ramifications  would  have  to  be  considered.  In  the  process  of 
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executing  a cross-channel  transfer  within  the  redundant  system,  two  receptions  of  that 
transfer  must  be  anticipated  by  the  receiving  computers  software.  Since  only  one  I/O  device 
can  be  serviced  by  a computer  at  one  time,  it  would  be  necessary  for  each  channel 
(computer)  to  sequentially  service  its  two  receivers.  Thus,  the  first  receiver  must  be  selected, 
data  retrieved,  and  reset  with  this  process  repeated  for  the  second  receiver. 

The  simplest  possible  cross-channel  interchange  of  data  could  be  executed  by  each 
computer  initiating  their  transmitter,  followed  by  each  computer  processing  the  data  out  of 
both  of  their  receivers.  In  order  for  this  interchange  to  be  successful,  the  computation  time 
between  processing  the  transmitter  routine  and  processing  the  first  receiver  routine  must 
v account  for  the  actual  transmission  delay  plus  the  worst-case  timing  skew  between  channels 

(asynchronous  operation  within  the  synchronized  frame  time).  To  understand  this,  consider 
what  would  happen  if  the  fastest  computer  executes  the  receiver  routine  before  the  slowest 
computer  has  completed  the  transmitter  routine.  There  would  be  no  data  or  erroneous  data 
in  the  fastest  computer’s  receiver. 

The  abo»'e  transmitter/receiver  routines  assume  CP  control  of  the  cross-channel 
process,  where  time  delays  or  unrelated  instructions  have  to  be  set  up  to  provide  the 
required  transmit-receive  separation.  It  is,  however,  difficult  to  know  worst-case  timing 
skews,  and  providing  wide  timing  margins  could  result  in  a compromise  of  the  total  program 
execution  time,  especially  if  the  cross-channel  information  is  keyed  to  continuing  the 
main-line  program.  Thus,  a more  elaborate  cross-channel  software  structure  could  be 
developed  to  synchronize  the  fastest  computer  with  the  slowest  computer  during 
cross-channel  exchanges.  The  following  requirements  for  such  a process  were  therefore 
postulated: 


1)  Cross-channel  exchange  synchronization  must  occur  by  transmitting  and  then 
receiving  (both  receivers),  and  by  checking  the  reception  to  determine  its  validity. 


2)  If  a reception  is  not  valid,  the  receiver  routine(s)  would  again  be  repeatedly 
executed  until  a good  reception  oc<  irs. 

3)  A loop  execution  count  for  item  2 above  must  be  made  with  provisions  to  exit 
the  loop  after  a specific  number  of  iterations. 

4)  A signal  selection  or  reasonableness  criteria  routine  would  have  to  be  used  in  item 
1 above  to  establish  the  reception  validity. 


This  software  approach  potentially  minimizes  the  cross-channel  infor.nation 
transmission/reception  time  and  protects  the  system  from  a single  point  failure  for  any 
transmitter  failure.  Operating  the  cross-channel  interface  utilizing  the  I/O  interrupt  would 
result  in  saving  processor  time,  but  the  single-point  failure  hazard  makes  this  approach 
impractical. 
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C.2  SSCU  INTERFACE  DESCRIPTION/FMECA 

♦ 

The  WWCS  failure  status  and  error  reset/computational  reset  control  functions  are 
provided  by  the  system  status  and  control  unit  (SSCU)  shown  in  figure  C-5.  The  SSCU  also 
has  the  control/display  functions  associated  with  preflight  test.  The  following  discussion 
covers  only  the  former  functions  and  pertains  to  the  failure  indicators  (LOCAL,  1ST, and 
2ND)  in  the  upper  right  corner  of  the  SSCU  panel  (fig.  C-5)  and  to  the  control  functions 
found  in  the  lower  left  01  that  panel. 

The  error  reset  and  computational  reset  controls  are  spring  return,  single  action,  triple 
contact  switches  (fig.  C-6).  Error  reset  attempts  to  reset  the  failure  detection/indication  on 
those  monitored  functions  that  are  considered  off-line  and  do  not  affect  the  system 
configuration.  Computational  reset,  on  the  other  hand,  initializes  the  basic  state  of  the 
WWCS  configuration  by  removing  all  software  time  history  and  by  activating  the  reset  logic 
for  all  monitored  functions  that,  upon  failure  detection,  modify  the  WWCS  redundancy 
structure.  The  computational  reset  action  is  visualized  as  a ground  operation  only  and  would 
be  interlocked  to  prevent  its  activation  in  flight. 

Failure  status  information  on  the  C1U,  STRU,  and  CU  is  all  combined  in  software  to 
formulate  a system/channel  failure  state.  The  resultant  system  failure  state,  along  with 
functional  level  failure  information,  is  then  transmitted  to  the  SSCU  via  a device  controller 
interface  that  is  under  CP  control  (fig.  C-7). 

Any  active  failures  within  the  computational  reset  control  logic  or  failure  state 
information  paths  will  be  readily  apparent.  The  computer  system  or  one  channel  will  be 
held  in  computational  reset  (system  main-line  software  will  not  execute),  or  a portion  or  all 
of  the  display  lamps  will  be  illuminated.  Potential  latent  failures  exist  in  both  the  error  reset 
logic  and  the  failure  display  information  paths.  Error  reset  failures  can  activate  the  reset 
lines  to  the  various  monitor  functions  whereby  an  actual  failure  would  not  be  registered  or 
displayed.  Such  latent  failures  must  be  cleared  through  a preflight  check  process. 

Control  and  display  failure  modes  generally  do  not  represent  a hazard  within  a 
redundant  system  as  long  as  basic  isolation  (redundant  signal  independence)  ground  rules  are 
followed.  However,  preflight  checks  of  these  functions  ultimately  require  flighlcrew 
interaction. 


C.3  SERVOTRANSMITTER/RECEIVER  UNIT 

The  STRU  is  an  input/output  interface  between  the  WWCS  and  the  flight-control 
system  hydromechanical  servosystem.  Its  design  utilizes  the  same  A/D  and  D/A  conversion 
electronics  discussed  for  the  ICPS  computer  interface  unit  in  section  A. 5.  The  following 
STRU  description  and  FMECA  cover  only  the  differences  between  the  STRU  and  the  ICPS 
CIU. 
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C.3.1  STRU  Description 

The  STRU  performs  the  same  I/O  operations  as  found  in  the  CIU.  However,  the  STRU 

* interface  to  the  WWCS  computer  units  is  such  that  each  channel  of  the  STRU  can  receive 
different  signal  (command  path)  information  during  the  same  time  interval.  Thus,  each 
channel  of  the  STRU  can  have  a unique  voted  input  at  any  given  instant  in  time;  whereas 
each  CIU  channel  presents  the  same  (identical)  output  for  any  instant  in  time.  This 
difference  is  illustrated  in  figure  C-8.  Essentially,  the  difference  amounts  to  three 

* transmitter  registers  in  the  computer  unit  dedicated  to  the  STRU  and  only  one  transmitter 
register  dedicated  to  the  CIU. 

Failure  status  information  of  the  STRU  is  also  treated  different  than  that  of  the  CIU. 
The  failure  information  is  transferred  to  the  computer  unit  via  a packed  16-bit  data  word 
rather  than  as  independent  discrete  signals.  The  16-bit  word  also  contains  the  STRU  to 
computer  unit  discrete  signal  transfers.  Figure  C-9  presents  the  bit  assignment  for  this 
failure-state/discrete  information  data  word.  Figure  C-10  illustrates  the  CIU  and  STRU 
discrete  input  interfaces  to  the  computer  unit. 

The  clock  signal  generation  circuits  within  the  STRU  differ  slightly  to  that  of  the  CIU 
in  that  only  one  clock  pulse  is  used  in  the  STRU  compared  to  a clock  pulse  and  strobe  pulse 
in  the  CIU.  The  algorithm  time  counter  is  also  different.  The  STRU  counter  counts  through 
eight  time  windows  with  16  algorithm  times  in  each  window,  where  the  CIU  counts  through 
a cycle  of  128  algorithm  times.  However,  the  effects  of  failure  modes  in  these  generation 
circuits  will  be  similar  to  the  failure  modes  discussed  for  the  CIU  in  appendix  A. 

The  final  difference  between  the  STRU  and  CIU  is  that  the  STRU  does  not  contain  a 
12-bit  overflow  detector  and  limiter  for  the  D/A  operation.  The  difference  is  covered  in  the 
illustration  presented  in  figure  C-8.  Not  having  the  overflow  protection  places  the  burden  of 
limiting  the  output  digital  command  on  the  programmer. 

C.3.2  STRU/CIU  FMECA  Comparison 

The  STRU  has  all  the  A/D  and  analog  input  shift  register  and  timing  gate  failures  that 
were  discussed  for  the  CIU  in  section  A.  The  analog  output  failures  for  the  voter,  D/A 
register,  and  D/A  will  also  be  the  same  as  discussed  in  appendix  A. 

A failure  in  the  computer  unit’s  CIU  transmitting  register  causes  a first  failure 
detection/indication  in  all  three  CIU’s,  where  a failure  in  one  of  the  STRU  transmitting 
registers  will  only  cause  a first  failure  in  one  channel  of  the  STRU. 

A failure  in  STRU  to  computer  unit  transmitter,  which  causes  all  zeros  to  be 
transmitted,  is  detected  by  the  loss  of  the  line  check  bit  provided  in  the  discrete  data  word 
(bit  15,  fig.  C-9,  always  a one).  For  the  alternate  case  where  the  transmitter  transmits  all 
ones,  LOCAL,  1ST,  and  2ND  failures  will  be  indicated;  thus,  the  failures  will  be  detected. 
Intent  failure’s  can  occur  in  the  failure  status  lines  to  the  transmitter,  where  a failure  will 
not  be  reflected  by  a zero-to-one  state  change  of  the  failure  registering  logic. 

As  with  the  CIU,  any  failure  of  the  STRU  timing  structure  should  be  detected  by 
monitors  in  the  computer  unit.  However,  these  type  of  failures  in  one  channel  of  the  STRU 
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C.4  SYNCHRONOUS  LOGIC  INTERFACE 
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C.4  1 SLI  Functional  Description 
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The  S1L  timing  and  control  operation  (fig.  C-13)  essentially  performs  two  functions. 
The  first  is  to  generate  SLI  clocking  signals.  The  clocking  signals  are  used  to  drive  a bit-time 
shift  register  and  a word  time  counter.  The  outputs  of  the  shift  register,  word  counter,  and 
clock  signals  are  then  used  to  perform  the  second  function,  to  control  the  data  manipulation 
within  the  SLI  electronics. 

A key  SLI  control  signal  is  compare.  During  each  algorithm  time  (where  there  are  1 28 
I/O  algorithm  times  every6.144  jusee,  as  set  forth  by  the  C1U  design),  a counter  is  run  that 
registers  the  number  of  SLI  put  and  take  accesses  to  the  memory.  The  SLI  has  primary 
control  of  the  memory  during  this  series  of  put  and/or  take  operations,  where  each 
operation  consumes  one  memory  cycle  (1  /asec).  When  the  counter  has  incremented  to  a 
preset  number  of  SLi  operations  for  that  algorithm  time,  the  compare  signal  is  generated 
This  signal  is  used  to  release  memory  accesses  to  be  made  by  the  SLI  each  algorithm  time 
vary  from  one  to  eight  and  are  established  through  the  programming  of  read-only-memory 
devices. 

Control  of  the  memory  by  the  SLI  is  scheduled  through  the  memory  switchover  logic 
shown  in  figure  C-14.  The  memory  address  register  is  multiplexed  to  pass  SLI  generated 
addresses  or  CP  generated  addresses  depending  upon  which  function  is  using  the  memory. 
The  effective  SLI  address  is  controlled  by  a counter  that  is  incremented  for  each  SLI 
memory  access,  reset,  and  repeated  every  I/O  frame  time  iteration.  The  SLI  addresses 
decoded  in  a ROM  to  identify  which  I/O  unit  is  being  processed  (CIU  A,  CIU  B,  etc.)  and  to 
set  whether  the  data  are  to  be  written  into  or  fetched  from  memory. 

Write  protection  logic  for  the  lower  32  words  of  memory  exists  to  permit  address 
overlaying  of  the  core  memory  and  a semiconductor  read  only  memory.  This  logic  controls 
which  memory  will  be  accessed.  If  data  are  to  be  processed  (read/written),  the  core  memory 
will  be  accessed.  If  an  instruction  is  to  be  fetched,  the  ROM  memory  will  be  accessed. 
Control  for  this  logic  is  contained  in  the  microprogramming  circuits  of  the  CF. 

C.4.2  SLI  FMECA 

Table  C-2  summarizes  the  SLI  failure  modes  and  their  effect  on  the  system.  Nearly  all 
failures  are  detectable  by  the  output  data  monitors  in  the  STRU  and  CIU’s.  In  fact,  failures 
upstream  of  any  of  the  output  data  paths  will  be  detected  whether  or  not  they  are  being 
used  in  the  application  configuration. 

No  latent  failures  could  be  found  in  the  SLI  circuits,  outside  the  majority  logic 
voter/monitors  used  in  the  receiver  circuits.  The  active  nature  of  the  multiplexed  data 
processing,  which  generally  extends  from  the  incoming  signals  to  one  or  more  of  the  output 
commands,  forces  any  failure  (even  on  a bit  level)  to  be  propagated  to  the  output 
voter/monitor  where  it  will  be  detected.  The  integrity  of  the  MLV  functions  in  the  SIL 
would  have  to  be  established  through  a preflight  test. 


C.5  WWCS  MEMORY  SYSTEM 

The  memory  used  in  the  MCP-703  computer  unit  is  fabricated  from  ferrite  cores.  This 
memory  is  used  to  store  program  instructions  (execution  instructions  for  the  CP)  data  for 
intermediate  calculations  from  the  CP,  constants,  and  data  pertaining  to  the  peripheral 
interface  input  and  output  operations.  The  memory  has  a capacity  for  approximately  8,000 
words  (8  k),  with  each  word  18-bits  long.  The  MCP-703  CP  utilizes  16-bits  of  the  word;one 
bit  is  used  for  parity  checks;  the  remaining  bit  is  unused. 

C.5.1  Memory  Description 

r Thc  memory  system  is  essentially  comprised  of  the  four  functional  sections  shown  in 
figure  C-l  5.  The  timing  and  control  section  operates  the  core  stack  independent  of  the  CP 
an  administrates  the  memory/data  available  logic  going  to  the  computer  system.  The  core 
stack  decod  ng  logjc  selects  the  particular  core  cell  location(s)  as  a function  of  the  memory 
address  register,  rhe  core  stack  holds  binary  data  (information)  as  a function  of  the 
magnetic  flux  orientation  of  each  core  cell.  The  memory  data  register  retrieves  or  modifies 
ata  within  the  core  as  a function  ot  the  desired  operation  of  the  associated  interface. 

The  memory  timing  is  mechanized  using  a delay  line  constructed  from  a distributed  LC 

r m a „ na,TiyaI  °f  a"  initiatC  SignaU  the  memory  timinS  chain  commences  (fig. 
at  i A , n,p-n°Pjatches  the  arrival  of  this  signal,  and  100  ns  later  a time  tap  from  the 
delay  line  clears  the  flip-flop.  This  puts  a uniform  100-ns  pulse  through  the  delay  line.  The 
puise  is  then  sent  to  a series  of  latches  whose  functions  are  to  develop  the  memory  control 

recycled  1Cn  ^ C’ain  completes  lts  cyc,c’  il  wiH  not  restart  until  the  initiate  signal  is 

When  the  power  to  the  memory  is  good  (as  determined  from  a power  monitor)  a 
power  status  signal  enables  the  initiate  signal  to  enter  the  timing  chain.  However,  this  signal 
is  implemented  so  that  when  the  power  goes  down,  the  memory  will  stay  active  for  at  least 
Msec  longer.  When  power  first  comes  up,  a power  on  reset  signal  is  used  to  clear  the 
timing  control  latches  so  that  incompatible  control  modes  will  not  exist. 

The  memory  address  register  (fig.  C-16)  passes  the  selected  memory  word  to  a 
decoding  module  which  translates  the  selected  word  identification  into  specific  core  stack 
cell  locations.  The  decoded  signals  pass  through  driver/decoder  circuits  that  control  the 
power  transistors  that  drive  the  memory  control  lines.  The  current  generator  for  the  line 
drivers  is  simply  power  supply  voltage  with  a series  resistor  to  limit  the  current  to  the 
appropriate  level.  This  resistance  is  trimmed  as  a function  of  stack  temperature  to  allow  for 
changes  in  the  inductive  coupling  (geometry  situation)  caused  by  heat. 

, T!!e  oST  dT  regiSter  (MDR)  can  be  loaded  ,rom  memory-  from  the  SI.I  logic,  or 
from  the  CP.  When  data  are  loaded  into  the  MDR  from  memory,  (memory  read  cycle)  the 

contents  of  that  memory  location  are  destroyed  (characteristic  operation  of  a core 

memory).  The  data,  however,  are  restored  back  into  the  core  (memory  restore  cycle)  at  the 

sTTnrTp  ,S„drbrted;°  the  USing  interfacc-  Data  ]oa^d  into  the  MD,(  by  either  the 
LI  or  CP  will  be  placed  into  the  core  during  the  restore  cycle  of  the  MDR/memory 

operation.  In  this  case,  the  read  cycle  can  be  reviewed  as  a clearing  operation  The  MDR 
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therefore  distributes  data  to  four  locations:  back  to  the  memory  core,  to  the  SLI  for 
transmission  to  the  interface  units;  to  the  central  processor  B buss  for  CP  use;  and  to  a 
parity  checker  to  establish  that  the  core  data  holds  to  an  odd  parity.  When  a parity  error  has 
been  detected,  an  interrupt  is  sent  to  the  CP  that  forces  the  computer  into  a memory  fault 
routine  if  a high  priority  interrupt  is  not  present.  The  parity  error  does  not  prevent  further 
processing  of  instructions,  as  recovery  from  this  error  is  handled  in  software.  The  interrupt 
is  cleared  by  execution  of  the  clear  arithmetic  fault  instruction. 

i 

C.5.2  Memory  FMECA 

The  memory  system  failure  modes  and  effects  are  summarized  in  table  C-3.  Three 
potential  latent  failure  areas  were  identified.  The  first  is  whether  the  parity  error  checker  is 
operational;  the  second  is  whether  data  have  been  lost  in  a core  cell  or  group  of  core  cells 
because  of  a loss  of  magnetic  orientation  of  physical  damage  to  the  cell (s)  such  as  a crack, 
and  the  third  relates  to  the  circuits  (or  software)  that  must  respond  to  a parity  error 
detection. 

The  loss  of  core  information  with  parity  error  circuits  operational  can  only  become  a 
hazard  if  it  occurs  in  a section  of  code  that  will  not  be  processed  under  normal 
circumstances  over  an  extended  period  of  time  (e.g.,  code  which  is  to  respond  to  a failure 
detection).  The  hazard  arises  if  the  core  loss,  over  time,  occurs  in  two  computers  and  then  a 
failure  causes  the  faulty  area  to  be  processed.  A parity  error  would  most  likely  be  detected, 
and  two  computers  responding  to  a parity  error  would  be  considered  a single  system  failure. 

' 

Once  a parity  error  has  occurred  and  the  CP  responds  by  activating  the  appropriate 
interrupt  software  routine,  the  parity  error  detection  has  to  be  reset  using  a clear  arithmetic 
fault  instruction.  If  this  logic  fails,  such  that  the  clearing  action  did  not  take  place,  future 
parity  error  detections  will  not  initiate  an  interrupt  signal.  This  type  of  latent  failure 
situation  not  only  blocks  the  parity  error  detection  but  all  lower  priority  arithmetic  fault 
interrupts. 


C.6  MCP-703  (WWCS)  CENTRAL  PROCESSOR 

The  CP  of  the  MCP-703  consists  of  circuits  that  control  the  interpretation  and 
execution  of  the  instructions  and  data,  which  are  stored  in  the  memory.  These  circuits  are 
referred  to  as  the  MCP-701  central  processor.  The  basic  architecture  of  the  CP  is  a three-buss 
system  as  shown  in  figure  C-l  7.  This  structure  cycles  all  data  processing  through  the  arith- 
metic section. 

The  instruction  repertoire  and  register  control  is  developed  through  microprogram- 
ming. The  operation  code  of  an  instruction  is  used  as  an  address  for  a ROM.  The  output  of 
this  ROM  forms  a starting  address  for  an  additional  ROM.  The  output  of  this  second  ROM 
develops  the  actual  control  logic  which  manipulate  the  electronics  comprising  the  CP.  With 
the  use  of  this  microprogramming  design,  modifications  to  instruction  execution  can  be 
made  by  substitution  of  the  ROM  element  without  actually  changing  the  wiring.  Thus,  there 
exists  some  potential  for  modifying  the  CP  through  changes  of  the  software,  which  define 
the  ROM  program. 


235 


I 


Failure  modes  analysis  on  previous  functional  elements  have  been  conducted  primarily 
on  a bottoms-up  approach.  With  such  a method,  failures  are  postulated  at  the  component 
level,  and  the  failure  response  propagation  analyzed  until  its  effect  on  the  system  operation 
could  be  determined.  Essentially,  all  possible  input  combinations  must  be  tried  for  all 
possible  failures.  For  complicated  circuits,  such  an  exhaustive  analysis  would  take  a very 
long  time.  For  instance,  a 16-bit  hardware  multiplier  can  have  2^2  possible  output  states.  If 
we  were  to  check  this  function  at  an  analysis  rate  of  10^  cases/sec,  it  would  take  about 
1 190  hr  to  complete  the  task. 

For  the  MCP-701  central  processor  shown  in  detail  in  figure  C-18,  a middle-up  analysis 
methodology  was  postulated  for  investigation  of  possible  latent  failures.  This  approach  was 
undertaken  due  tj  the  enormous  manpower  and  time  that  would  be  involved  to  complete  a 
bottoms-up  analysis  easily  understood  after  observing  the  complexity  of  figure  C-18.  The 
results  from  either  method  (i.e.,  an  identification  of  the  latent  failure  prone  areas  in  hard- 
ware) should  be  the  same. 


C.6.1  MCP-701  FMECA  Approach 

The  basis  of  a middle-up  analysis  is  to  look  at  the  digital  computer  at  the  instruction 
level,  since  a general  purpose  digital  computer  is  nothing  more  than  a device  for  sequentially 
processing  instructions.  Each  instruction  can  be  defined  as  a series  of  functional  steps  where 
it  can  be  assumed  that  any  of  the  functional  steps  can  fail.  Depending  on  the  specific 
hardware  design,  the  definition  of  a single  functional  failure  may  relate  to  one  or  many 
actual  hardware  failures-normally  many.  The  instruction  functional  failues  must  then  be 
evaluated  with  the  computer  system-flight  resident  software  to  determine  whether  the  in- 
struction failure  mode  would  be  detectable.  In  doing  this,  failure  states  can  be  classified  as 
being  immediately  detectable,  latent,  or  trivial. 

To  relate  these  failure  states  to  the  MCP-701  CP,  the  following  examples  are  given.  An 
immediately  detectable  failure  would  be  a failure  of  the  add-tc-upper  register  (ADU) 
instruction,  where  the  sum  of  two  numbers  were  in  error  in  one  computer;  three  computers 
were  assumed  to  be  operational  with  an  output  bit-for-bit  monitor  such  as  that  used  in  the 

wwes. 

A trivial  failure  would  be  a failure  of  the  ADU  instruction  to  set  the  sign  adder  (SA)  bit 
of  the  CP  status  register,  where  no  other  instruction  of  the  application  program  utilized  (or 
tested)  the  state  of  the  SA  bit.  A latent  failure  would  be  where  the  setting  of  the  SA  bit  had 
failed,  and  where  the  SA  state  would  be  utilized  in  a portion  of  the  program  that  would  be 
active  only  after  a detectable  failure. 

In  this  case,  the  SA  bit  setting  latent  failure  could  occur  in  time,  in  two  computers,  and 
result  in  the  wrong  system  response  to  the  detected  failure. 

Following  the  above  failure  mode  analysis  and  failure  state  classification  identification, 
latent  failure  possibilities  must  be  looked  at  in  great  detail  to: 

• Establish  that  the  failure  mode  is  physically  impossible  and  can  be  rejected. 
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• Identify  specific  piece-part  or  software  elements  that  cause  such  a failure  and 
redesign  the  processor  to  eliminate  the  failure  mode. 

• Develop  a self-test  hardware/software  program  to  specifically  exercise  th“ 
function,  as  required,  to  preserve  system  functional  reliability  goals. 

C.6.2  MCP-701  FMECA  Example 

A simple  example  was  selected  as  an  exercise  of  the  FMECA  approach  discussed  above. 
The  flight -control  system  function,  shown  in  figure  C-19,  was  implemented  using  the 
instruction  repertoire  of  the  MCP-701.  The  specific  code  necessary  to  represent  the  function 
is  shown  in  figure  C-20.  For  this  exercise,  the  executive  and  I/O  code  has  been  ignored. 

Some  further  assumptions  are  made.  It  is  assumed  that  the  input  signals,  1NPUT1  and 
1NPUT2,  are  moving  about  zero  (i.e.,  are  not  biassed  positively  or  negatively).  This  implies 
that  all  bits  in  the  word  will  be  active  all  the  time.  A further  assumption  is  that  a system 
bit-for-bit  output  voter  monitor  is  being  used  in  a triplex  system  so  that  any  error  in  any 
calculation  will  be  detected  at  the  output  of  the  triple-channel  computations. 

The  following  presents  the  details  of  the  analysis  of  the  first  instruction,  LDU,  of  the 
sample  application  program.  The  instruction  execution  is  based  on  the  hardware  architec- 


ture  of  the  MCP-701 . 

Instruction 

Operation 

Explanation 

LDU  1NPUT1 

(1NPUT1)  - UR 
ZA,  SA 

Bring  the  contents  of  location 
1NPUT1  to  the  UR.  Set  flags 
ZA,  SA  as  appropriate. 

Failure  Modes 

Explanation/Analysis 

Failure  Detection 

(1NPUT1)?  - UR 

Fail  to  select  correct 
address  - 1NPUT1 

Immediate 

(1NPUT1 ) -*•  ?UR 

Data  transfer  failure 
(see  assumptions) 

Immediate 

(1NPUT1)  -►  UR? 

Failure  to  select  UR 
for  data 

Immediate 

SA? 

SA  set  incorrectly 
(SA  is  not  tested 
after  LDU) 

Trivial 

ZA? 

ZA  set  incorrectly 
(ZA  is  not  tested 
after  LDU) 

Trivial 

A summary  of  the  analysis  of  the  remaining  sample  problem  instructions  is  presented  in 
table  C-4. 

From  this  example,  it  was  concluded  that  the  middle-up  approach  had  merit.*Evcn 
though  the  analysis  was  not  extended  over  the  FCD  task  application  model,  an  extra- 
polation of  the  results  indicated  that  considerable  manpower  and  time  savings  could  be 
realized  over  an  analysis,  which  would  be  based  totally  on  the  detailed  hardware  design. 

•■ki  /■ tH,S  approach  can  be  initiatcd  as  soon  as  the  system  hardware/software  becomes 
visible  (i.e.,  complete  hardware  and  software  details  are  not  needed  before  the  study  can 
egin).  It  was  determined  in  the  example  problem,  that  the  potential  latent  failure  in  the 
multiply  instruction  could  be  uncovered  using  a random  number  multiply  check  routine  as  a 
selt-test  operation  during  a software  background  mode. 
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FIGURE  C- 18. -CONCL  UDED 


CODE 


INPUT1 

-DS15*  .006144* 
TEMPI 


COMMENTS 


(6.144  m/t  FRAME  TIME) 


TEMPI 


INTEGRATOR 


-DS15'  .50* 


LIMITER 


•DS15'  .50* 


+.5  LIMIT 


-0315*  -.50* 


SFNM 


-DS15*  -.50* 
TEMPI 


SKIP  FOR  NO  LIMIT 
-.6  LIMIT 

PREVENT  SATURATION 


INPUT2 


TEMP2 


-DS15*  .006144* 
TEMP2 


TEMP2 


MULTIPLY  BY  0.5 
START  FIRST  ORDER  LAG 


INTEGRATE  FOR  FIRST  ORDER 


TEMPI 

OUTPUT 


SUMMING  JUNCTION 


FIGURE  C-20.-MCP-701  CODE  REQUIRED  FOR  FIGURE  C-19 
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TABLE  C-1. -CROSS-CHANNEL  DATA  LINK  FMECA 


TABLE  C-2.-SL!  FAILURE  MODE  EFFECTS  ANAL  YSIS 


Inability  to  generate  error  during  test  of  memory  parity. 


TABLE  C-4.  —FUNCTIONA L FAILURE  MODES  ANAL  YSIS 
OF  MCP-701  INSTRUCTIONS 


Instruction 

Operation  ; 

i 

Failure 

Failure  mode/comment 

ADU  X 

(add  to  upper  register) 

(X)  + UR  -*  UR 
SA,  ZA,  AF 

(X)  ? + UR  -+  UR 
(X)  + ? UR  -*  UR 

(X)  + UR  ? -*  UR 
(X)  + UR-»  ? UR 
(X)  + UR  -*  UR  ? 
SA? 

ZA  ? 

AF  ? 

Immediate 

Immediate-but  could<be  latent  if  the 

signals  were  not  active 

Immediate 

Immediate 

Immediate 

Trivial  (not  used  in  program) 

Trivial  (not  used  in  program) 
Immediate-depends  on  AF  software 

MPY  X 
(multiply) 

(X)  + UR-*UR 
SA,  ZA,  AF 

(X)xUR  -*  UL 
(X)  x?  UR  -*  UL 

(X)  x UR  ? -►  UL 
(X)  xUR-»  ? UL 
(X)xUR  -*•  UL? 
SA? 

ZA  ? 

AF  ? 

Immediate 

Latent  possibility-because  of  high 

number  of  states 

Immediate 

Immediate 

Immediate 

Trivial 

Trivial  ; 

Immediate 

STU  X 

(Store  upper  register) 

(UR)  -♦  X 
SA,  ZA 

(UR)?-*  X 
(UR)-*?  X 
(UR)-*X? 
SA  ? 
ZA? 

Immediate  i 

Immediate 

Immediate 

Trivial 

Trivial 

CPU  X 

(Compare  to  upper 
register) 

UR  - (X) 

SA 

ZA 

UR  ? - (X) 
UR  - ? (X) 
UR-(X)  ? 
SA? 
ZA? 

Immediate 

Latent  possibility /trivial 

Immediate 

Immediate 

Trivial  (not  used  in  this  program) 

JMP  X 

(Jump  uncon- 
ditionally) 

X -*■  PC 

X ? -*  PC 
X -+  ? PC 
X -*  PC? 

Immediate-program  loses  control 
Immediate— program  loses  control 
Immediate 

SFMI  N 

(Skip  forward  on  minus) 

IF  SA  = 1 

PC  + N -*  PC 
ELSE 

PC  + 1 -*  PC 

IF(SA*0)PC+N  -*  PC 
IF(SA=1)PC?+N-*PC 
1 F (S  A*  1 )PC+?N  -*  PC 
1 F ( S A=  1 ) PC+N  ? -*  PC 
IF(SA=1)  PC+N -* ?PC 
IF(SA*1)PC+N-*  PC? 
SA? 

immediate 

Immediate 

Immediate 

Immediate 

Immediate 

Immediate 

Trivial-not  retested  after  SFMI  until 
set  again 

SFNM  N 

(Skip  fv  ward  on  not 

minus) 

IF(SA»0) 

PC+N  -*  PC 
ELSE 

PC+1  -*•  PC 

IF(RA=1)PC+N-*PC 
IF(SA=0)PC?+N-*PC 
IF(SA=0)PC+?N-H»C 
IF(SA=0)PC+N?-*PC 
1 F(SA=0)  PC+N  -*  ?PC 
IF(SA=0)PC+N-*  PC? 
SA? 

Immediate 

Immediate 

Immediate 

Immediate 

Immediate 

Immediate 

Trivial-not  retested  after  SFNM 

F. 
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Instruction 


Operation 


Failure 


Failure  mode/comment 


SRS  1,  UR 
(Shift  right, 
repeat  sign) 

UR  shifted  1 UR 

UR?shifted  1 -*■  UR 
UR  shifted  I?-*' UR 
UR  shifted  1 -*■  UR? 
UR  shifted  1 -►  UR 

immediate 

Immediate 

Immediate 

Immediate 

SBU  X 

UR  - (X)-*UR 

UR  ? - (X)  -►  UR 

Immediate 

(Subtract  from 

SA,  ZA,  AF 

UR  -?(X)  -►  UR 

Immediate-but  could  be  latent  if 

upper  register) 

signals  were  inactive 

UR-(X)  ? -♦  UR 

Immediate 

UR-(X)  -*  ?UR 

Immediate 

UR-(X)  -♦  UR? 

Immediate 

SA? 

Trivial 

ZA? 

Trivial 

* 

AF? 

Immediate 
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APPENDIX  D 


WWCS  BUILT-IN-TEST 


Built-in-test  (BIT)  refers  to  those  elements  of  hardware  and  software  within  the 
MCP-703  system,  WWCS,  that  directly  contribute  to  the  subsystem  self-administered 
operational  integrity  check.  The  primary  responsibility  for  the  design/development  of  the 
BIT  was  given  to  the  General  Electric  Company  as  part  of  their  role  in  the  development  of 
the  WWCS.  The  design  of  BIT  was  not  the  direct  result  of  a detailed  FMECA  but  evolved 
parallel  to  the  hardware  design  and  various  failure  mode  studies  in  progress  as  the  hardware 
was  being  constructed.  The  basic  structure  of  BIT  followed  the  guidelines  presented  in 
section  4.3.3  of  this  document. 

Table  D-l  contains  a detailed  tabular  sequence  of  the  tests  within  the  BIT  software 
program.  Tests  that  are  looped  through  three  times  in  order  to  test  the  permuted  combina- 
tions of  channel  failures  are  considered  a test  group.  There  are  six  such  groups;  they  deal 
with  testing  the  MLV  and  their  associated  monitors.  These  MLV  test  groups  are,  in  general, 
conducted  as  follows: 

The  normal  MLV  logic  is  defined  as  V = A-  B+B  C+C  A,  where, 

V = voted  output 

A,  B,  and  C = inputs  from  channels  A,  B,  and  C,  respectively 
+ = logical  OR  operation 
• = logical  AND  operation 


The  MLV  test  steps  are: 


Pass  through 
group 

Step 

number 

Fail 

Operations  verified 

Pass  1 

1 

A 

V = B C and  channel  A will  indicate  first 
failure 

2 

AB 

V ^ C and  second  failure  will  indicate 

Pass  2 

3 

B 

V = C A and  channel  B will  indicate  first 
failure 

V 

4 

BC 

V ^ A and  second  failure  will  indicate 

Pass  3 

5 

C 

V = A B and  channel  C will  indicate  first 
failure 

r 

6 

C A 

V ^ B and  second  failure  will  indicate 

Test  steps  2, 4 and  6 verify  that  no  single  channel  can  drive  the  output. 
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TABLE  D-1f.-MCP-701  BUILT-IN-TEST  TEST  SEQUENCE 


A,  B,  and  C channels. 


TABLE  D-1f.— Concluded 


Monitors;  A,  B,  and  C = channels. 


REFERENCES 


1.  Redundant  Flight-Critical  Control  System  Evaluation,  “Analog  and  Digital  Systems 
Descriptions,”  FAA-SS-73-2-1,  June  1974. 

2.  Redundant  Flight-Critical  Control  System  Evaluation.  “Analog  and  Digital  Performance 
Comparisons,”  FAA-SS-73-2-2,  October  1974. 

3.  SST  Longitudinal  Control  System  Design  and  Design  Processes.  “Hardened  Stability 
Augmentation  Design,”  FAA-SS-73-1 , June  1973. 

4.  J.G.  McKinney,  An  Introduction  to  the  Computer  Simulator.  D25-71060-1,  Boeing 
Commercial  Airplane  Company,  January  1970. 


297 


